Create 1-3 HTTP message-(1).md

HTTP Perfect Guide/1-3 HTTP message-(1).md

@@ -0,0 +1,184 @@
+# 1부 3장 : HTTP 메시지
+
+HTTP가 배달원이라면, HTTP 메시지는 소포와 같다.
+
+# 1. 메시지의 흐름
+## 1) HTTP 메시지란
+
+HTTP 애플리케이션 간 주고받은 데이터의 블록들
+
+- 메시지의 내용, 의미를 설명하는 텍스트 메타 정보로 시작한다.
+- 그 다음 선택적으로 데이터가 담김.
+- 클라이언트, 서버, 프락시 사이를 흐른다.
+
+메시지의 방향에 따라 ‘인바운드’, ‘아웃바운드’, ‘업스트림’, ‘다운스트림’이라고 부른다.
+
+<br/>
+<br/>
+
+## 2) 인바운드, 아웃바운드
+
+메시지가 원 서버로 향하는 것을 “인바운드로 이동한다”고 하며, 
+모든 처리가 끝나 사용자 에이전트로 돌아오는 것을 “아웃바운드로 이동한다”고 한다.
+
+클라이언트 — GET /index.html HTTP/1.0  —→ 서버 : 인바운드(서버방향)으로 흐른다.
+
+클라이언트 ←— HTTP/1.0 200 OK —— 서버 : 아웃바운드(사용자 에이전트 방향)으로 흐른다.
+
+
+<br/>
+<br/>
+
+## 3) 업스트림 다운스트림
+
+메시지 발송자(보내는 쪽)은 수신자(받는 쪽)의 업스트림이다.
+
+HTTP 모든 메시지는 다운스트림으로 흐른다. 즉 발송자가 수신자에게 메시지를 보낸다.
+
+클라이언트가 서버에게 요청시 보내는 메시지 : 클라이언트가 발송자, 서버가 수신자
+
+서버가 클라이언트에게 요청받은 리소스와 처리결과를 보내는 메시지 : 서버가 발송자, 클라이언트가 수신자. 
+
+# 2. 메시지의 각 부분
+## 1) HTTP 메시지의 구성요소
+
+HTTP 메시지는 시작줄, 헤더 블록, 본문으로 세 부분으로 이루어진다.
+
+- 시작 줄 : 이 메시지가 어떤 메시지인지 서술한다
+- 헤더 블록 : 메시지의 속성 서술. 본문에 대한 많은 정보를 전달. 
+ex) Content-Type : 본문이 어떤 형식인지 알려준다. : plain-text, text/html, image/jpeg 등등.
+Content-length : 본문의 크기를 말해준다.: 19byte ..
+- 본문 : 선택적으로 데이터를 담는다. 시작줄이나 헤더와 다르게, 텍스트나 이진 데이터를 포함할 수 있으며, 비어있을 수도 있다.
+
+
+<br/>
+<br/>
+
+## 2) 시작 줄과 헤더를 분리하는 CRLF
+
+시작 줄, 헤더는 줄 단위로 분리된 아스키(ASCII) 문자열이다. : CRLF로 구분된다. 
+
+> **잠깐, CRLF가 뭐지?**
+캐리지 리턴과 개행문자로 구성된 두 글자의 줄 바꿈 문자열.
+
+옛날 타자기(종이를 꽂아서 쓰는) 사용 시 생겨난 용어.
+**Carrage Return**은 구식 타자기를 치면서 종이의 오른쪽으로 이동하며 글씨가 써지기 때문에, 줄  바꿈 시 종이의 맨 앞(왼쪽)으로 이동시키는 것.
+> 
+> 
+> **Line Feeding**은, 줄 바꿈 시 종이를 위로 올려서 아래 줄로 이동하는 것. 
+> 
+> OS, 프로토콜마다 개행문자의 ASCII 값이 다르다. 
+> HTTP에서는 ASCII의 CR+LF를 개행문자로 사용하도록 규정하고 있다.
+> 
+> CR : Carrage Return = “\r” = “0x0D”(아스키코드)
+> 
+> LF : Line Feed = “\n” = “0x0A”
+> 
+> - http메시지 예시
+> 
+> `POST /login.php HTTP/1.**\r\n**Host: www.test.co.kr**\r\n**Content-Tpye: application/x-www-form-urlencoded**\r\n\r\n**id=tset&pw=test123`
+> 
+> → 개행문자CRLF(\r\n)으로 시작줄과 헤더를 구분, 헤더의 끝은 개행문자 두 개로 구분.
+> 
+> 참고로, 윈도우에선 CRLF(\r\n)를 다 써줘야 개행으로 인식하고, 리눅스 계열에서는 \n만 써주어도 개행으로 인식한다. ⇒ 가끔 윈도우 CRLF와 부딪혀서 github 에러가 날 때 있음..
+> 
+
+HTTP명세에 따르면, 줄 바꿈 문자열은 CRLF 모두 사용해야 하지만, 그냥 개행 문자도 줄바꿈으로 받아들일 수 있어야 한다. 잘못 만들어진 HTTP 애플리케이션 중 Carrage Return과 Line Feeding을 모두 전송하지 않는 것도 있기 때문.
+
+
+<br/>
+<br/>
+
+
+## 3) 메시지 문법
+
+### 요청 메시지와 응답 메시지
+
+- 모든 http메시지는 요청, 응답 메시지로 분류된다.
+- 요청 메시지는 웹 서버에 어떤 동작을 요구하며,
+- 응답 메시지는 요청의 결과를 클라이언트에게 돌려준다.
+- 두 메시지 모두 기본적인 구조는 같다.
+
+### 요청 메시지 형식
+
+```
+<메소드> <요청url> <버전>
+<헤더>
+<엔터티 본문>
+```
+
+```jsx
+GET /specials/saw-blade.gif HTTP/1.0
+Host: www.joes-hardware.com
+
+//get메소드라서 엔터티본문은 없다.
+```
+
+### 응답 메시지 형식
+
+```jsx
+<버전> <상태코드> <사유구절>
+<헤더>
+<엔터티 본문>
+```
+
+```jsx
+HTTP/1.0 200 OK
+Content-Type: image/gif
+Content-length: 8572
+그리고 본문에 요청한 이미지파일을 담아서 보내준다.
+```
+
+
+<br/>
+<br/>
+
+
+## 4) 메시지 구성요소
+
+### 메소드(method)
+
+서버가 리소스에 대해 수행해주길 바라는 클라이언트에서 요청한 동작.
+
+- GET, POST, PUT, OPTIONS, HEAD 등이 있다.
+
+### 요청 URL(request URL)
+
+요청 대상이 되는 리소스를 지칭하는 완전한 URL 또는 요청하고자 하는 리소스가 있는 URL의 경로 부분. 
+완전한 URL이 아니라 해도, 경로 부분이 절대 경로이기만 하면 대체로 문제가 없으며, 서버는 생략된 호스트, 포트가 자신을 가리키는 것으로 간주한다.
+
+### 버전(version)
+
+이 메시지에서 사용 중인 HTTP의 버전. 
+
+형식 : `HTTP/<메이저>.<마이너>` ⇒ 메이저와 마이너는 모두 정수다.
+
+### 상태 코드(status code)
+
+요청 중 무슨 일이 일어났는지 설명하는 세 자리 숫자. 첫 번째 자리 숫자는 상태의 일반적 분류를 나타낸다 - 성공, 실패, 등 - 뒤에서 모든 상태코드에 대해 다룰 것임
+
+### 사유 구절(reason-phrase)
+
+숫자로 된 상태 코드를 사람이 잘 이해할 수 있도록 설명해주는 짧은 문구. 
+오로지 사람에게 읽히기 위한 목적으로만 존재한다.
+
+→ `HTTP/1.0 200 Failed` 나 `HTTP/1.0 200 OK` 나 둘 다 성공으로 처리해야한다.  사유 구절은 그저 사람에게 읽히기 위한 추가적인 정보이기 때문이다.
+
+상태 코드 이후부터 줄바꿈 문자열까지가 사유구절임.
+
+### 헤더들(headers)
+
+0개 이상의 헤더 이름, 콜론(:), 공백(선택적 요소), 값, CRLF가 순서대로 나타난다. 
+
+개행 문자 두 개(\r\n\r\n)는 헤더의 끝을 알려준다. 
+
+→ 헤더 목록의 마지막은 빈 줄로 끝난다. 그리고 새 개행 문자로 엔터티 본문의 시작을 표기한다.
+
+http/1.1과 몇몇 버전은 http 요청, 응답에 특정 헤더가 포함되어야 유효한 것으로 간주한다.
+
+### 엔터티 본문 (entity body)
+
+모든 메시지가 엔터티 본문을 갖진 않는다. 데이터를 포함하지 않을 땐, 그냥CRLF로 끝나게 된다. (엔터티에 대해선 15장에서 자세히 다룬다.)
+
+헤더나 엔터티 본문이 없더라도 HTTP 헤더목록은 항상 빈 줄(CRLF)로 끝나야 한다!
+하지만 엔터티 본문이 없을 때 실수로 마지막 CRLF를 빠뜨리는 클라/서버들이 있다.  → 호환을 위해 마지막 CRLF를 빠뜨린 메시지도 잘 받을 수 있어야 한다.