Request-Line OR Status-Line
[Header CRLF]
CRLF
[ Body ]

Start Line

Request
Response

헤더 중 X가 붙은 경우, 커스텀 헤더임
Pragma: 옛날 캐시 정책 Deprecated
Cache-Control: 캐시 정책인데, 기능이 추가된 것들
Connection: close, keep-alive 두 개의 옵션이 있음

Stateless Protocol

HTTP는 상태가 없는 프로토콜이다.
- 즉, 이전 Request에 대해서 고려하지 않는다는 것
  - 터미널 같은 경우, 이전 요청에 종속적인 결과를 줌
- TCP 통신을 하게되면 연결과정에 오버헤드가 생김
- 그런데 어차피 계속 요청, 응답을 할거라면 요청 보낼때마다 이를 연결하고 끊는 것은 비효율적
- 그래서 해당 헤더가 있다.
- 그런데 이게 문제가 있을 수도 있다.
- 대용량 서비스 같은 경우에 해당 옵션을 킨다는 것은 소켓하나를 점유하고 있다는 것이기 때문
- 만약 특정 이벤트를 진행해서 순간적으로 사람들이 엄청 몰린다고 해보자. 이 상황이면 켜는 것이 좋을까, 끄는 것이 좋을까?
  - 끄는 경우
    - 더 많은 클라이언트들 처리할 수 있다.
  - 키는 경우 (요즘)
    - 근데 끄게 되었을 때, 문제가 생기는데 페이지는 떴지만, 이미지는 뜨지 않는 상황이 발생했다.
    - 다시 재요청을 하는데, 그럴 경우 해당 요청이 뒤로 밀리게 되기 때문
    - 즉, 이렇게 되면 한사람이 느끼는 서비스 품질이 상당히 떨어지게 된다.
    - 보통 들어와서 사이트 전체를 보고, 로그인을 하든 어떠한 행동을 취하는 것까지가 하나의 액션이기 때문이다.
    - 그렇기 때문에 요즘에는 keep alive를 키되, 해당 연결 지속 시간을 줄이는 것으로 변화하는 추세이다.

Blank Line

header와 body를 구분해주는 라인이다.
CR (Carriage return)
- \r
- Ascii 13
LF (Line Feed)
- \n
- Ascii 10
타자기에서 발생한 어원
- 이전에는 종이가 움직이고 아이핑하는 것은 타자기의 중앙에 위치했음
- 이 때, 종이를 움직이게 만드는 것을 carriage라 불렀음
- 한줄을 다 치게되면, 왼쪽으로 옮겨졌던 종이를 다시 오른쪽으로 옮겨야 함
  - 이 과정에서 나온 것이 Carriage return
- 또 다음줄을 쳐야했기 때문에 종이를 위로 올려야 함
  - 이 과정에서 나온 것이 Line feed
현재
- 이제는 Carriage Return을 할 필요가 없음
- Line Feed만 사용하면 의미를 충분히 전달할 수가 있음
- 하지만..
  - Window: CRLF 사용 \r\n
  - Unix 계열: LF만 사용 \n
  - 에디터에서는 이를 똑같이 인식해주나, 이전 HTTP 메시지를 직접 작성한 경우, \r\n 이 없어서 곤역을 치렀던 경험이 있음

Body

텍스트 데이터
- 일반 텍스트, JSON, XML, HTML 등

이진 데이터
- 이미지, 오디오, 비디오 등
폼 데이터
- HTML 폼을 통해 제출된 데이터
기타 형식