[내일배움캠프] HTTP 와 TCP

program-yam 2024. 9. 29. 13:56

2024. 9. 29. 13:56

HTTP에 대해 알아야할 것

1. Request <-> Resonpse 구조 + 비연결성

하나의 Request가 있으면 그에 대응하는 Response가 있다. 다시 말해,Request가 없으면 Response를 보내지 않는다.
연결을 유지하지 않기 때문에 리소스를 줄일 수 있어서 많은 트래픽을 빠르게 처리가 가능하다.

2. Stateless ( 무상태 )

연결을 한번 하고 끊기 때문에, 이전에 일어났던 일( 상태 )를 저장하고 있지 않는다.
매번 새로운 요청을 처리한다. ( 세션, 쿠키, DB로 해당 요청에 대한 정보를 임의로 저장해 처리하긴 한다. )

3. HTTP 프로토콜의 메세지 구조

HTTP 프로토콜의 메세지 구조는 위 그림과 같다.
이 중에서 중요하게 살펴볼 부분은 헤더( header ) 부분인데, 메세지에 필요한 모든 부가 정보가 들어있고, 그림처럼 넣고 싶은 내용을 임의로 추가 할 수도 있다.

General Header

Date : 현재 시간
Pragma : 캐시제어( no-cache ), HTTP/1.0에서 쓰던 것으로 HTTP/1.1에서는 Cache-Control이 쓰인다.
Cache-Control : 캐시 제어 + no-cache( 모든 캐시를 쓰기 전에 서버에 해당 캐시를 사용해도 되는지 확인 ) + public( 공유 캐시에 저장해도 됨 ) + max-age( 캐시의 유효시간을 명시 ) + private( '브라우저' 같은 특정 사용자 환경에만 저장 ) + must-revalidate( 만료된 캐시만 서버에 확인 ) + no-store( 캐시를 저장하지 않음 )
Transfer-Encoding : body 내용 자체 압축 방식 지정. 본문에 데이터 길이가 나와서 야금야금 브라우저가 해석해 화면에 뿌려줄 때 이 기능을 사용한다. ( 'chunked'면 본문의 내용이 동적으로 생성되어 길이를 모르기 때문에 나눠서 보낸다는 의미 )
Upgrade : 프로토콜 변경시 사용
Via : 중계( 프록시 )서버의 이름, 버전, 호스트명
Content-Encoding : 본문의 리소스 압축 방식( transfer-encoding은 body 자체이므로 다르다 )
Content-type : 본문의 미디어 타입(MIME) 예) application/json, text/html
Content-Length : 본문의 길이
Content-Language : 본문을 이해하는데 가장 적절한 언어. 예) ko
Expires : 자원의 만료 일자
Allow : 사용이 가능한 HTTP 메소드 방식 예) GET, HEAD, POST ...
Last-Modified : 최근에 수정된 날짜
ETag : 캐시 업데이트 정보를 위한 임의의 식별 숫자
Connection : 클라이언트와 서버의 연결 방식 설정 HTTP/1.1은 kepp-alive로 연결을 유지하는게 디폴트

Request / Response Header

● request header form은 웹브라우저가 웹서버에 요청하는 것을 텍스트로 변환한 메세지들이다.

● Request Line : 어떤 웹서버로 접속( Host 부분 )해서, 어떠한 방식( HTTP / 1.1 )으로, 어떠한 메소드( GET )를 통해 무엇을( /doc/test/.html ) 요청했는지에 대한 메시지가 담겨있다. ( GET /test.html http 1.1 )

● Host : 요청하려는 서버 호스트 이름과 포트번호

● User-agent : 클라이언트 프로그램 정보 예) Mozilla / 4.0, Windows NT5.1 ( 이 정보를 통해 서버는 클라이언트 프로그램( 브라우저 )에 맞는 최적의 데이터를 보내줄 수 있다. )

● Referer : 바로 직전에 머물렀던 웹 링크 주소( 해당 요청을 할 수 있게된 페이지 )

● Accept : 클라이언트가 처리 가능한 미디어 타입 종류 나열 예) */* - 모든 타입 처리가능, application/json - json데이터 처리 가능

● Accept-charset : 클라이언트가 지원가능한 문자열 인코딩 방식

● Accept-language : 클라이언트가 지원가능한 언어 나열

● Accept-encoding : 클라이언트가 해석가능한 압축 방식 지정 예) gzip, deflate

● Content-location : 해당 개체의 실제 위치

● Content-disposition : 응답 메세지를 브라우저가 어떻게 처리할지 알려준다. 예) inline, attachment; filename='jeong-pro.xlsx'

● Content-Security-Policy : 다른 외부 파일을 불러오는 경우 차단할 리소스와 불러올 리소스 명시

예) default-src 'self' -> 자기 도메인에서만 가져온다.

default-src 'none' -> 외부파일은 가져올 수 없다.

default-src https -> https로만 파일을 가져온다.

● If-Modified-Since : 여기에 쓰여진 시간 이후로 변경된 리소스를 취득. 페이지가 수정되었으면 최신 페이지로 교체하기 위해 사용된다.

● Authorization : 인증 토큰을 서버로 보낼 때 쓰이는 헤더

● Origin : 서버로 Post 요청을 보낼 때 요청이 어느 주소에서 시작되었는지 나타내는 값 ( 이 값으로 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 난다. )

● Cookie : 쿠키 값 key-value로 표현된다. 예) attr1=value1; attr2=value2

● response header form은 웹브라우저가 요청한 메세지에 대해서 status 즉, 성공했는지 여부( 202, 400 등), 메세지, 그리고 요청한 응답 값들이 body에 담겨 있다.

● Location : 301, 302 상태코드일 때만 볼 수 있는 헤더로 서버의 응답이 다른 곳에 있다고 알려주면서 해당 위치( URL )를 지정한다.

● Server : 웹서버의 종류 예) nginx

● Age : max-age 시간내에서 얼마나 흘렀는지 초 단위로 알려주는 값

● Referrer-policy : 서버 referrer 정책을 알려주는 값 예) origin, no-referrer, unsafe-url

● WWW-Authenticate : 사용자 인증이 필요한 자원을 요구할 시, 서버가 제공하는 인증 방식

● Proxy-Authenticate : 요청한 서버가 프록시 서버인 경우 유저 인증을 위한 값

● 응답 상태 코드 ( 200, 202, 404 등 )

HTPP는 Application Layer 에서 동작하는 프로토콜이고, transport laye( 전송계층 )의 위에서 동작한다.

전송계층의 대표적인 프로토콜은 TCP / UDP가 있다.

HTTP는 TCP와 UDP 둘 중 하나의 연결을 통해서 동작한다. ( 결론적으로 TCP / UDP 프로토콜이 없으면 동작 불가 )

예외)

HTTP / 2 : 멀티플렉싱 기술의 등장으로 한번의 연결을 재사용하는 것이 가능하다.

HTTP / 3 : QUIC( UDP )위에서 동작한다.

TCP

HTTP는 비연결성이지만 TCP는 연결지향성이다.

TCP는 데이터교환을 할 때 무조건 연결을 가진다.
HTTP의 Req <-> Res가 발생할 때 밑에서 TCP 연결이 이루어진다.
TCP는 3-handshake라고 하는 연결 과정을 가진다.

TCP 통신방법

양방향 통신( Full-Duplex ) 순서

서버는 접속 요청을 받기 위한 소켓을 연다. ( Listen )
클라이언트는 소켓을 만들고, 서버에 접속을 요청한다. ( Connect )
서버는 접속 요청을 받아서 클라이언트와 통신할 소켓을 따로 만든다. ( Accept )
소켓을 통해 서로 데이터를 주고 받는다. ( Send & Receive 반복 )
통신을 마치면 소켓을 닫는다. ( Close ( 상대방은 Receive로 인지할 수 있다. ) )

웹소켓( Websocket )

HTTP 프로토콜 위에서 동작하는 실시간 양방향 통신( Full-Duplex )

특징

1. 실시간 통신

웹소켓은 연결이 활성화된 상태에서 빠르고 지속적인 메세지 교환을 허용한다. 이로 인해 에플리케이션은 사용자에게 지연 없는 인터랙션을 제공할 수 있다.

2. 양방향 통신( Full-Duplex )

클라이언트와 서버가 동시에 서로에게 베세지를 보낼 수 있다. 이는 한 쪽이 다른 쪽의 메세지를 기다리지 않고도 독립적으로 메세지를 송수신 할 수 있음을 의미한다.

3. 지속적 연결

웹소켓 연결이 수립되면, 그 연결은 클라이언트나 서버가 명시적으로 종료할 때까지 유지된다. 이는 오버헤드를 줄이고 빠른 데이터 전송을 가능하게 한다.

4. 낮은 오버헤드

웹소켓은 데이터 패킷의 헤더가 매우 작기 때문에 오버헤드가 낮다. 이는 효율적인 네트워크 자원 사용을 가능하게 한다.

5. HTTP와의 호환성

웹소켓은 HTTP 포트( 80과 443 )을 통해 작동하기 때문에 기존 웹 인프라와 잘 통합된다. 웹소켓 연결은 HTTP 연결을 통해 초기화되며, 이후 전이중 통신 채널로 전환된다.

각 프토토콜의 헤더 비교

HTTP 헤더

GET /data HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/90.0.4430.212
Accept: application/json
Cookie: sessionToken=abcdef; userID=12345

보통의 HTTP Request Header의 일부분 ( 여기에 더해 General Header까지 추가하면 대략 수백 바이트의 양을 가진다. )

웹소켓 헤더

  0x81 0x05

연결 이후 데이터 교환할때의 websocket의 헤더
극도로 간소화되어 있지만, FIN 비트, Opcode, Mask 비트, Payload 길이 정보가 포함되어 있다.

TCP 패킷 헤더

  Source Port:       54321
  Destination Port:  80
  Sequence Number:   123456789
  Acknowledgment Number: 987654321
  Data Offset:       5 (Header Length: 20 bytes)
  Reserved:          0
  Flags:             [ACK, PSH]
  Window Size:       65535
  Checksum:          0x1a2b
  Urgent Pointer:    0
  Options:           [No options]
  Payload Data:      "Hello, TCP!"

TCP 패킷의 구조

TCP 패킷, 종종 세그먼트라고 불리는 것은 다음과 같은 주요 부분으로 구성된다.

소스 포트번호( 16비트 ) : 발신자의 포트 번호
목적지 포트번호( 16비트 ) : 수신자의 포트 번호
시퀀스 번호( 32비트 ) : 데이터 스트림 내에서 이 세그먼트의 위치를 식별하기 위한 번호
응답 번호( 32비트 ) : 다음에 기대하는 데이터의 시퀀스 번호
헤더 길이( 4비트 ) : 헤더의 크기를 나타냄
예약된( 3비트 ) : 향후 사용을 위해 예약된 공간
플래그( 9비트 ) : 연결 설정, 관리, 종료를 제어하는 다양한 플래그
윈도우 크기( 16비트 ) : 수신자가 받을 준비가 되어 있는 버퍼의 크기
체크섬( 16비트 ) : 오류 검사를 위한 값
긴급 데이터 포인터( 16비트 ) : 긴급 데이터의 끝을 가리키는 포인터
옵션( 가변 길이 ) : 필요에 따라 추가적인 옵션을 포함할 수 있음
데이터( 가변 길이 ) : 실제 전송할 데이터

웹소켓의 연결방법은 TCP의 연결방법 ( 3-way-handshake)를 닮아있다.

웹소켓은 기본적으로 TCP 연결 위에서 작동하기 때문에, 웹소켓 연결을 시작하기 전에 TCP의 표준 연결 방법인 3-way handshake가 수행된다. 하지만 웹소켓은 이후에 추가적인 핸드셰이크 과정을 진행해 웹소켓 특유의 연결을 완성한다.

'내일배움캠프' 카테고리의 다른 글

[내일배움캠프][TIL] 37일차 - 모의 면접 (1)	2024.10.01
[내일배움캠프][TIL] 36 일차 - 개인과제 스켈레톤 코드 (2)	2024.09.30
[내일배움캠프][TIL] 35일차 - Node.js 심화 강의 듣기 (1)	2024.09.27
[내일배움캠프][TIL] 34일차 - 팀 변경 (0)	2024.09.26
[내일배움캠프] 33일차 - 팀프로젝트 최종점검 (0)	2024.09.24

얌생