[그림으로 배우는 H&N CH.2]
HTTP
- HTTP : 클라이언트와 서버 간 통신
- 반드시 클라이언트 측에서 리퀘스트를 보내고 서버 측에서 그 결과를 리스폰스로 보낸다.
- 반드시 클라이언트 측에서 통신이 시작 (리퀘스트가 없는데 리스폰스를 보낼 수 없음)
1.1 리퀘스트 메세지
POST /form/entry HTTP/1.1
Host: hackr.jp
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 16
name=ueno&age=37
- 리퀘스트의 구성요소
- 메소드 : POST
- 리소스를 나타내는 리퀘스트 URI : /form/entry
- HTTP 버전 번호 : HTTP/1.1
- 리퀘스트 헤더 필드 : Host: hackr.jp ~ Content-Length: 16 (option)
- 엔티티(객체) : name=ueno&age=37 (option)
1.2 리스폰스 메세지
HTTP /1.1 200 OK
Date: Tue, 10 Jul 2021 06:50:15 GMT
Content-Length : 362
Content-Type : text/html
<html>
...
- 리스폰스의 구성요소
- 서버의 HTTP 버전 : HTTP /1.1
- 상태코드 : 200
- 상태코드 설명 : OK
- 리스폰스 헤더 필드 : Date: Tue, 10 Jul 2021 06:50:15 GMT ~ Content-Type : text/html
- 바디 : ...
1.3 스테이트리스 프로토콜
- HTTP는 스테이트리스 프로토콜임
- 스테이트리스 프로토콜 : 상태를 계속 유지하지 않는 프로토콜 → 이전에 보낸 리퀘스트 또는 리스폰스를 기억 못함 (많은 데이터를 빠르고 확실하게 처리하기 위해)
- 새로운 리퀘를 보낼 때마다 새로운 리스폰스가 생성됨
1.4 리퀘스트 URI
- URI를 사용하여 인터넷 상의 리소스를 지정
- URI를 리퀘스트 URI 형식으로 포함하는 방법
1.5 HTTP 메소드
**메소드는 대문자, 소문자를 구별 → 대분자로 기재할 것!
- GET : 리퀘스트 URI로 식별도니 리소스를 가져오라고 요구
- POST : 엔티티를 전송하기 위해서 사용
- PUT : 리퀘에 포함된 파일(엔티티)을 리퀘 URI로 지정한 곳에 보존하도록 요구
- HEAD : get과 같은 기능 but 메세지 바디는 반환x, URI 유효성 & 리소스 갱신 시간 확인용
- DELETE : 리퀘 URI로 지정된 리소스의 삭제 요구
- OPTIONS : 리퀘스트 URI로 지정한 리소스가 제공하고 있는 메소드 조사용
- TRACE : 웹 서버에 접속하여 자신에게 통신을 되돌려 받는 루프백 발생 → 리퀘를 보낸 곳에 어떤 리퀘가 가공되어 있는지 조사 가능
- CONNECT : 프록시에 터널 접속 확립 요구
1.6 지속 연결
- HTTP 초기 버전 : HTTP 통신을 한 번 할 때마다 TCP에 의해 연결 및 종료를 해야 했음 → 통신량 증가
- 지속 연결 : 어느 한 쪽이 명시적으로 종료하지 않는 이상 TCP 연결을 계속 유지
- 장점 : 연결 및 종료가 반복되는 오버헤드가 줄어듦 → 서버에 대한 부하 경감, 리퀘&리스폰스가 빠름
1.7 파이프라인화
- 지속 연결이 가능해지면서 여러 리퀘를 보낼 수 있는 파이프라인화도 가능해짐
- 리퀘를 보낸 후, 리스폰스가 오지 않아도 여러 리퀘를 병행해서 보내는 것이 가능
1.8 쿠키
- HTTP : 스테이트리스 프로토콜 → 인증확인이 필요한 웹 페이지의 경우 새로운 페이지에 갈 때마다 로그인 해야 함
- 쿠키 : 리퀘스트와 리스폰스에 쿠키 정보 추가해서 클라이언트의 상태를 파악
- 순서
- 클라이언트 측에서 리퀘스트 송신
- 서버 측에서 리스폰스 + 쿠키 붙여서 송신
- 이후 쿠키를 가지고 있는 클라이언트 측에서 리퀘스트+쿠키를 보냄
- 서버는 서버 상의 기록을 확인해서 이전 상태를 알 수 있게됨