[TIL/개념] 성공과 실패를 결정하는 1%의 네트워크 원리: 1-1. HTTP 리퀘스트 메시지 작성

* TIL/개념: 최대한 공식 문서 & 책을 기반으로 배운 내용을 정리

* 현재 취준생으로 풋내기 개발자가 쓰는 글입니다.

* 그러니 조언과 지적 및 훈수는 언제나 환영입니다! 댓글로 많이 달아주세요!

성공과 실패를 결정하는 1%의 네트워크 원리

웹 브라우저가 메시지를 만든다.
1. HTTP 리퀘스트 메시지를 작성한다.
2. 웹 서버의 IP 주소를 DNS 서버에 조회한다.
3. 전 세계의 DNS 서버가 연대한다.
4. 프로토콜 스택에 메시지 송신을 의뢰
TCP/IP의 데이터를 전기 신호로 만들어 보낸다.
케이블의 앞은 LAN 기기였다.
액세스 회선을 통해 인터넷의 내부로!
서버측의 LAN에는 무엇이 있는가?
웹 서버에 도착하여 응답 데이터가 웹 브라우저로 돌아간다.

사용자가 브라우저에 URL을 입력하면 URL을 해독하여 리퀘스트 메시지를 만든다.

브라우저가 입력받은 URL을 해독한다.

URL

사용자가 브라우저 상단의 주소창에 URL을 입력한다.

그러면 브라우저는 가장 먼저 URL을 해독한다.

그렇다면 URL이 무엇이고, 어떻게 해독하는 것인가?

URL(Uniform Resource Locator)의 정의는

인터넷에서 웹 페이지, 이미지, 비디오 등 리소스의 위치를 가리키는 문자열이다.

우리가 흔히 아는 http로 시작하는, 브라우저 검색창에 입력하는 문자열 또한 URL의 일종이다.

그러나 URL은 http로 시작하는 것만 있지 않고, 종류가 다양하며, 각각 나타내는 정보 또한 조금씩 다르다.

또한 여기서 http와 같은 문자를 프로토콜이라고 하며,

URL에서 프로토콜은 리소스 출처에 엑세스 하는 방법을 나타낸다.

위 그림에서 알 수 있듯 URL의 형식은 앞 문자열, 즉 프로토콜에 따라 조금씩 다르다.

그럼 브라우저는 결국 프로토콜을 먼저 확인한 후, URL 형식에 따라 해독을 하게 된다.

HTTP 프로토콜의 URL 해독

웹 서버를 대상으로 한 HTTP 프로토콜 형식의 URL에 대해서 보면,

해당 형식은 아래와 같이 표현되어야 한다.

기본적으로는 http 프로토콜을 사용하겠다라는 표시 + 웹 서버 명 + 파일의 경로명이 지켜져야한다.

이 때 파일의 경로명에서 "/"은 디렉토리를 나타내는 것으로,

파일의 경로명은 웹 서버에 있는 파일 중 어디에 엑세스할 것인가를 나타낸다.

그럼 이를 토대로 아래와 같이 http://www.sample.com/dir/file1.html 이 URL로 들어왔을 때,

형식에 맞게 해석을 하게 된다.

이 때 해석의 뜻은 www.sample.com 이라는 웹 서버에 /dir/file1.html에 엑세스하겠다.라는 의미이다.

파일 경로가 생략된 경우

그런데 우리는 실제로 위와 같은 형식만이 아닌 여러 형식의 URL을 봐왔다.

아래와 같은 URL은 파일 경로에서 다소 생략된 형태이다.

그렇다면 이때는 어느 파일에 엑세스 하는지 어떻게 알 수 있을까?

a. 파일명이 생략된 경우

http://www.sample.com/dir1/

dir1 디렉토리에 있는 것은 맞는데, 어느 파일인지 생략된 형태이다.

사실 URL에서는 이렇게 생략하는 형태도 가능하게 되어있다.

그럼 어떤 파일을 불러올까?

생략되었을 때 불러올 파일은 미리 서버측에 설정되어있으며

대부분 index.html 혹은 defaut.html 이라는 파일명으로 설정하게 된다.

즉, 해당 URL은 다음 URL과 동일하다.

http://www.sample.com/dir/index.html

b. 웹 서버의 도메인명만 쓴 URL

http://www.sample.com/

디렉토리명이 안보여서 없는건가..? 싶지만 끝에 /이 있다.

이 때 /는 디렉토리명, 즉 루트로 봐야하고 파일명이 생략되어있다고 봐야한다.

따라서 /index.html 혹은 /default.html이라는 파일에 액세스한다.

http://www.sample.com/index.html 혹은 http://www.sample.com/default.html

c. 끝의 /까지 생략

http://www.sample.com

이는 디렉토리명까지 생략된 형태인데, 실제로는 "/"가 있다고 본다.

따라서 b의 경우 처럼 /index.html 혹은 /default.html이라는 파일에 액세스한다.

http://www.sample.com/index.html 혹은 http://www.sample.com/default.html

d. 맨 끝에 /가 없으면서 이름이 붙여있는 경우

http://www.sample.com/dir1

다음과 같은 경우가 미묘한데

아무리 디렉토리명같은 이름으로 지어놓았어도, 확장자명 조차 없으니

dir1를 디렉토리로 봐야하는가? 혹은 파일로 봐야 하는가?

이때는 사실 두 가지 경우를 모두 고려한다.

만약 dir1이라는 디렉토리가 있으면 디렉토리로 보고,

dir1이라는 파일이 있으면 파일로 보는 것이다.

http://www.sample.com/dir1/index.html
http://www.sample.com/dir1.html

참고로 이는 실제로 같은 이름을 가진 파일과 디렉토리를 동시에 만들 수 없어서 가능한 것이다.

HTTP 리퀘스트 메시지를 만든다.

구체적인 메시지의 모습과 의미, 그리고 HTTP 프로토콜에 대해 알자!

HTTP 프로토콜

URL을 해독했으면, 이제 HTTP 프로토콜을 사용해서 웹 서버에 액세스를 해야한다.

HTTP 프로토콜은 클라이언트와 서버가 주고 받는 메시지의 내용이나 순서를 정한 것으로,

기본 개념은 아래와 같다.

1) 먼저 클라리언트에서 서버를 향해 리퀘스트 메시지를 보낸다.

이 때 리퀘스트 메시지 안에는 "무엇을", "어떻게 해서" 하겠다는 내용이 쓰이며

"무엇을"에 해당하는 내용이 URI,

"어떻게 해서"에 해당하는 내용이 메소드이다.

여기에 보충 정보를 나타내는 헤더 파일까지 같이 포함된다.

URI(Uniform Resource Identifier): 액세스 대상
- /dir1/file1.html이나 /dir/program1.cgi 등
- 혹은 http:로 시작하는 URL을 그대로 사용도 가능
메소드: 웹 서버에 어떤 동작을 하고 싶은지 전달
- URI로 나타낸 데이터를 읽고 싶다거나, 혹은 클라이언트에서 입력한 데이터를 URI로 나타낸 프로그램에 전달하고 싶다거나 등등의 동작
- GET, POST, HEAD, OPTION 등

2) 이런 리퀘스트 메시지가 웹 서버에 도착하면 해독한 후, "무엇을", "어떻게 하는지" 판단한다.

그리고 요구에 따라 동작한 후 결과 데이터를 응답 메시지에 저장한다.

이 때 응답 메시지에는 정상 종료되었는지, 혹은 이상이 발생했는지 나타내는 스테이터스 코드를 포함한다.

3) 그리고 헤더 파일과 페이지의 데이터가 이어지고, 이 응답 메시지를 클라이언트에 반송한다.

4) 클라이언트에 도착하면, 브라우저는 메시지 안에서 데이터를 추출해 화면에 표시한다.

메소드

리퀘스트 메시지를 보낼 때 "어떻게 해서"에 해당하는 메소드에 대해 간략하게 짚고자 한다.

지원하는 메서드 종류에는 아래와 같다.

메서드	HTTP 1.0	HTTP 1.1	의미
GET	사용	사용	URI로 지정한 정보를 도출한다 .파일의 경우 해당 파일의 내용을 되돌려 보내고, CGI 프로그램의 경우 해당 프로그램의 출력 데이터를 그대로 반송
POST	사용	사용	클라이언트에서 서버로 데이터를 송신한다. 폼에 입력한 데이터를 송신하는 경우에 사용
HEAD	사용	사용	GET과 거의 같다. 단 HTTP 메시지 헤더만 반송하고 데이터 내용을 돌려보내지 않는다. 파일의 최종 갱신 일시와 같은 속성 정보를 조사할 때 사용
OPTIONS		사용	통신 옵션을 통지하거나 조사할 때 사용
PUT	부가 기능	사용	URI로 지정한 서버의 파일을 치환한다. URI로 지정한 파일이 없는 경우에는 새로 파일을 작성한다.
DELETE	부가 기능	사용	URI로 지정한 서버의 파일을 삭제한다.
TRACE		사용	서버측에서 받은 리퀘스트 라닝과 헤더를 그대로 클라이언트에 반송한다. 프록시 서버 등을 사용하는 환경에서 리퀘스트가 치환되는 상태를 조사할 때 사용한다.
CONNECT		사용	암호화된 메시지를 프록시로 전송할 때 이용하는 메소드

위와 같이 지원하는 메서드는 다양한데, 이중 GET과 POST가 주로 쓰인다.

책에는 둘의 메서드에 대해 나와있지만, [TIL/질문] <GET과 POST의 차이>로 다음에 따로 정리하겠다.

리퀘스트 메시지

리퀘스트 메시지는 아래처럼 정해진 포맷이 있고,

반드시 이에 따라서 만들어야 한다.

각각의 요소에 대해 좀 더 알아보자.

리퀘스트 메시지
- 리퀘스트 라인: 웹 서버에 어떻게 할 것인가를 전달
  - 메소드
  - URI
  - HTTP 버전
- 메시지 헤더: 리퀘스트의 부가적인 정보
  - 한 행에 한 개의 헤더 필드가 포함된다.
  - ex. Date, Pragme, Connection, Cache-Control 등
  - 마지막 공백행까지 포함한다.
- 메시지 본문: 송신할 데이터
  - 클라이언트에서 서버에 송신하는 데이터
  - 폼 페이지에 입력한 데이터를 POST 메서드로 웹 서버에 보낼 때 등에 데이터가 들어감
  - GET인 경우 URI만으로 웹 서버가 무엇을 할 지 판단할 수 있으므로 마지막 행에는 아무 것도 없음
응답 메시지
- 스테이터스 라인
  - HTTP 버전, 스테이터스 코드, 응답 문구 포함
- 메시지 헤더
- 메시지 본문
  - 서버에서 클라이언트에 송신하는 데이터
  - 파일에서 읽은 데이터나 CGI 애플리케이션이 출력한 데이터

위 포멧을 바탕으로 폼에 데이터를 입력했을 때 리퀘스트 메시지가 어떻게 만들어지는지 보자.

예를 들어 브라우저에는 다음과 같이 보이는 form을 html에 포함시켰다.

<form action="/input" method="GET">
	<label for="keyword">입력:</label>
	<input type="text" name="input">
	<button type="submit" name="submitButton">확인</button>
</form>

여기서 method는 GET으로 설정했지만, POST도 가능하다.

그리고 여기서 입력창에 apple을 입력 후 확인 버튼을 눌러보자.

만약 GET으로 했을 경우 리퀘스트는 아래와 같이 apple이 URI에 포함된 형태로 만들어질 것이다.

GET /input?field1=apple HTTP/1.1
(이하 헤더 필드)

POST로 했을 경우에는 body에 포함된 형태로 만들어진다.

Post /input HTTP/1.1
(이하 헤더 필드와 공백 행)
Field1=apple

응답 메시지

리퀘스트 메시지를 만들어보내면, 서버에서는 응답 메시지를 되돌려보낸다.

응답 메시지
- 스테이터스 라인
  - HTTP 버전, 스테이터스 코드, 응답 문구 포함
- 메시지 헤더
- 메시지 본문
  - 서버에서 클라이언트에 송신하는 데이터
  - 파일에서 읽은 데이터나 CGI 애플리케이션이 출력한 데이터

이 때 첫번째 라인인 스테이터스 라인에는 스테이터스와 응답 문구가 포함되어야 한다.

스테이터스와 응답 문구는 내용이 같지만 용도와 형식면에서 다르다.

공통점: 정상 종료했는지, 혹은 오류가 발생했는지 등 리퀘스트의 실행 결과를 나타낸다.
차이점:
- 스테이터스: 숫자로 쓰여있으며, 프로그램에 실행 결과를 알려준다.
- 응답 문구: 문장으로 쓰여있으며, 사람에게 실행 결과를 알려준다.

코드값	설명
1xx	처리의 경과 상황 등을 통지
2xx	정상 종료
3xx	무언가 다른 조치가 필요함을 나타냄
4xx	클라이언트측의 오류
5xx	서버측의 오류

그렇다면 이를 토대로 아래와 같이

우산 이미지를 포함하는 페이지가 /umbrella.html에 있다고 가정하고,

GET을 보냈다고 해보자.

만약 정상적으로 동작했다면, 응답 메시지는 다음처럼 될 것이다.

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 327

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>우산(동요) 가사 출력하기</title>
</head>
<body>
    <h1>우산</h1>
    <p>이슬비 내리는 이른 아침에 <br>우산 셋이 나란히 걸어갑니다. </p>
    <img src="umbrella.jpg" alt="우산 이미지" width="300">
</body>
</html>

스테이터스 라인에서 스테이터스 코드는 200, 응답 코드는 OK인 것을 보아 정상적으로 불러왔음을 볼 수 있다.

주목할 것은 아래 우산 부분인데, 이미지를 불러와야하는 부분이 umbrella.jpg로 되어있다.

<img src="umbrella.jpg" alt="우산 이미지" width="300">

응답 메시지를 읽을 때 중요한 것은 URI는 한 개만으로 결정되어있다는 점이다.

즉 파일은 한 번에 한 개씩 읽을 수 있기 때문에 파일이 여러 개 포함되어 있다면, 파일을 따로 읽어야 한다.

따라서 위 예시에서는 다시 한 번 우산 이미지를 요청해서 받아야 한다.

GET /umbrella.jpg HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 6500

(이미지를 나타내는 바이너리 데이터)

브라우저가 다시 읽어와야 하는 파일에는 .jpeg와 같은 이미지 파일을 포함해

CSS, JavaScript, 폰트, 기타 리소스 파일이 있다.

요약

사용자가 URL을 입력하면 HTTP 리퀘스트 메시지를 작성한다.
브라우저는 가장 먼저 URL을 해독한다.
그리고 HTTP 프로토콜을 사용해서 웹 서버에 엑세스한다.
- HTTP 프로토콜: 클라이언트와 서버가 주고받는 메시지의 내용이나 순서를 정한 것.
- 클라이언트가 서버에게 보내는 리퀘스트 메시지
  - 무엇을(URI)과 어떻게 해서(메소드) 하겠다는 내용이 쓰인다.
- 서버가 클라이언트에게 보내는 응답 메시지
  - 스테이터스 코드와 응답 문구 포함
    - 둘의 내용은 리퀘스트 결과로 같으나 스테이터스 코드는 프로그램을 위한, 응답 문구는 사람을 위한 것.
- 리퀘스트 메시지에 쓰는 URI은 하나뿐이므로, 복수의 파일을 읽을 때는 웹 서버에 별도의 리퀘스트를 보낸다.

저작자표시

'CS > Network' 카테고리의 다른 글

[TIL/개념] 성공과 실패를 결정하는 1%의 네트워크 원리: 1-4 프로토콜 스택에 메시지 송신을 의뢰 (0)	2023.07.06
[TIL/개념] 성공과 실패를 결정하는 1%의 네트워크 원리: 1-3. DNS 서버의 연대 과정 (0)	2023.07.06
[TIL/개념] 성공과 실패를 결정하는 1%의 네트워크 원리: 1-2. 리졸버로 IP 주소를 DNS 서버에 조회 (0)	2023.07.06
[TIL/개념] OSI 7 계층 (0)	2023.06.01