[Network] 프로토콜 HTTP

책: 그림으로 배우는 Http & Network Basic - 2장 간단한 프로토콜 HTTP

---

• HTTP 프로토콜
  • 프로토콜이란? 서로 다른 하드웨어와 운영체제가 통신하기 위한 규칙
  • 반드시 한 쪽은 클라이언트, 한 쪽은 서버
• HTTP는 클라이언트로부터 Request 송신, 그 결과 서버가 Response 반환
  • 클라이언트로부터 통신이 시작
  • 서버 측에서 Request를 수신하지 않았는데, Response가 발생하는 경우는 없다.

---

HTTP 메시지란?

• 서버와 클라이언트 간에 데이터가 교환되는 방식

Request Message

 

1) start line

1.1) HTTP 메소드 (GET, POST 등)

• 서버가 수행해야 할 동작 명시

1.2) URL

1.3) HTTP 버전

 

2) Headers

2.1) Host: 서버 도메인 명과 TCP 포트

2.2) Accept: 서버에서 응답해야 하는 데이터 타입

2.3) Connection: 현재 전송이 완료된 후에 네트워크 접속을 유지할 것인지.

• 만약 keep-alive면 연결은 지속되고 동일한 서버에 대한 후속 요청을 수행할 수 있다.

3) Body

• 전송하는 데이터를 담고 있다.
• 모든 요청에 본문이 들어가지는 않는다.

Response Message

1) status line

1.1) 프로토콜 버전

1.2) 상태코드

1.3) 상태 텍스트

 

2) Headers

2.1) Server: 웹 서버의 종류

2.2) Content-Type: 리소스의 미디어 타입(content 형식)

2.3) Age: 객체가 프록시 캐시에 있었던 초 단위의 시간

 

3) Body

• 모든 응답에 본문이 들어가지는 않는다.

---

HTTP는 무상태(stateless) 프로토콜이다.

• HTTP에서는 새로운 request가 보내질 때마다, 새로운 respnse가 생성된다.
• 많은 데이터를 빠르고 확실하게 처리하는 범위성(scalability)을 확보하기 위해 간단하게 설계되었다.

Request URI로 리소스 식별

• HTTP는 URI(Uniform Resource Identifiers)를 사용하여 인터넷 상의 리소스를 지정한다.

---

HTTP 메소드

• GET: 리소스 획득
  • 멱등성: yes
• POST: 엔티티 전송
  • 멱등성: no
• PUT: 새로운 리소스를 생성 또는 대체
  • 그럼 POST와의 차이는? 멱등성!
  • 멱등성: yes
• PATCH: 리소스의 부분적인 수정
  • 멱등성: no
• HEAD: 메시지 헤더 취득
  • 멱등성: yes
  • 메시지 바디가 없다.
  • URI 유효성과 리소스 갱신 시간을 확인하는 목적
• DELETE: 파일 삭제
  • 멱등성: yes
  • 리퀘스트 URI로 지정된 리소스 삭제를 요구
• OPTIONS: 제공하고 있는 메소드의 문의
  • 멱등성: yes
  • 리퀘스트 URI로 지정한 리소스가 지정하고 있는 메소드를 조사
• TRACE: 경로 조사
  • 멱등성: yes
  • Web 서버에 접속해서 자신에게 통신을 되돌려 받는 루프백(loop-back) 발생
  • “Max-Forwards”라는 헤더 필드에 수치를 포함시켜 서버를 통과할 때마다 그 수치를 줄여나간다. 수치가 0이된 곳을 끝으로 리퀘스트를 마지막으로 수신한 곳에서 상태 코드 200OK 리스폰스를 되돌려 준다.
  • 클라이언트는 TRACE 메소드를 사용함으로써, 리퀘스트를 보낸 곳에 어떤 리퀘스트가 가공되어 있는지 등을 조사할 수 있다.
    • 프록시 등을 중계하여 origin 서버에 접속할 때, 해당 동작을 확인하기 위해 사용
• CONNECT: 프록시에 터널링 요구
  • 프록시에 터널 접속 확립을 요함으로써, TCP 통신을 터널링 시키기 위해 사용

---

지속 연결을 이해하기 위한 사전 지식(간단하게)

- 자세한 과정은 추후 업로드

1) 3-way-handshake

• TCP 통신을 이용하여 데이터를 전송하기 위한 네트워크 연결 과정
• 양쪽 모두 데이터를 전송할 준비가 되었다는 것을 보장

1.1) P → Q: SYN

• 접속 요청 프로세스 P가 연결 요청 메시지 전송. SYN

1.2) Q → P : SYN + ACK

• 접속 요청을 받은 프로세스 Q가 요청을 수락했고, P도 포트를 열어달라는 메시지를 전송. SYN + ACK

1.3) P → Q : ACK

• 접속을 요청한 프로세스 P가 수락 확인을 보내 연결을 맺는다. ACK

2) 4-way-handshake

• TCP의 연결을 해제하는 과정

2.1) 클라이언트가 연결을 종료하기 위해 FIN 플래그 전송

2.2) 서버는 클라이언트 요청을 받고, 확인 메시지 ACK 전송

2.3) 데이터를 모두 보내고 서버가 클라이언트에게 FIN 플래그 전송

2.4) 클라이언트는 FIN 메시지를 확인 후 ACK 전송

---

HTTP 지속 연결(Persistent Connections)

• 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지
  • TCP 커넥션의 연결과 종료를 반복되는 오버헤드를 줄여 서버의 부하를 경감
• 파이프라인화
  • 지속 연결은 파이프라인화(HTTP pipelining)를 가능하게 한다.
  • 응답을 기다리지 않고 다음 요청을 보낼 수 있다.

---

쿠키를 사용한 상태 관리

• 요청과 응답에 쿠키 정보를 추가해서 클라이언트의 상태를 파악

1) 서버에서 응답으로 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에서 보존

2) 다음에 클라이언트에서 같은 서버로 요청을 보낼 때, 자동으로 쿠키 값을 넣어서 송신

3) 서버는 클라이언트가 보낸 쿠키를 확인하여 어느 클라이언트가 접속했는지 체크하고, 서버의 기록을 통해 이전 상태를 알 수 있다.

---

References

우에노 센, 그림으로 배우는 HTTP & Network Basic, 2015

https://www.geeksforgeeks.org/tcp-3-way-handshake-process/

https://www.geeksforgeeks.org/tcp-connection-termination/

https://developer.mozilla.org/ko/docs/Web/HTTP