얌생

• 데이터가 제대로 도착했는지 확인한다
• 데이터가 최종적으로 도착할 애플리케이션이 무엇인지 식별한다.
  • 이는 네트워크 데이터를 어떤 애플리케이션에서 최종적으로 해석하고 사용할지를 의미한다.
  • 여기서 데이터는 HTTP 요청일 수도 있고, FTP를 사용한 파일 다운로드 요청일 수도 있고, 다양하다
• 목적에 따라 두가지 통신 방법이 존재한다.

1. 신뢰성과 정확성
   • 데이터를 목적지에 문제 없이 전달하는 방식
   • 이런 통신 방식을 다른 말로 연결형 통신이라고도 한다.
     • 연결형 통신은 상대방과의 통신 과정을 여러 번 확인하고 보내는 방식을 사용하게 된다.
     • 대표적인 프로토콜로 TCP가 있다.
2. 효율성
   • 데이터를 빠르고 효율적이게 전달하는 방식
     • 대표적인 프로토콜로 UDP가 있다.
     • UDP는 별도의 확인 절차가 없어서 스트리밍 방식과 같은 동영상 서비스에 유리하다.

TCP( Transmission Control Protocol )

• 전송 제어 프로토콜
• 전송 계층에서 신뢰할 수 있고 정확한 통신을 제공하는 연결형 프로토콜
• Segment 단위를 사용한다.

TCP는 포트 번호라는 주소로 통신한다. 이 포트 번호는 최종적으로 어떤 애플리케이션으로 향하게 될지를 정해주는 요소다.

Source Port

• 송신자의 포트 번호

Destination Port

• 목적지의 포트 번호

Sequence Number

• 송신 측에서 수신 측에 이 데이터가 몇 번째 데이터인지 알려주는 역할을 한다.
• 해당 번호를 통해 수신 측은 원래 데이터의 몇 번째 데이터를 받았는지 알 수 있다.
• TCP는 이를 이용하여 데이터가 손상되었거나 유실되었는지를 확인하고, 손상이나 유실되었다면 재전송 제어를 하게 된다.

Acknowledgment Number

• 수신 측이 몇 번쨰 데이터를 수신했는지 송신측에 알려주는 역할이다.
• 받은 데이터의 다음 번호의 데이터를 요청하는데 사용한다.

Offset

• TCP 헤더의 크기를 나타내는 값이다.
• 데이터의 시작 위치를 나타낸다.

Reserved

• 차후의 사용을 위해 예약된 필드
• 항상 0으로 설정한다.

TCP Flags

• 세그먼트의 용도와 내용을 결정하는 플래그 값이다.
• 총 8 bit로 이루어져 있으며, 각각의 비트에 연결의 제어 정보가 기록된다.
• 이를 이용해 TCP Connection을 맺고 TCP 통신을 하게 된다.

Window

• 한번에 전송할 수 있는 데이터 양을 뜻한다.
• 65535만큼의 값을 표현 가능하고, byte 단위를 사용한다. 64KB
• 한 번에 전송할 수 있는 데이터의 최대 크기가 65535 byte라고 생각 하면 된다.

Checksum

• 데이터를 송신하는 중에 발생할 수 있는 오류를 검출하기 위한 값이다.
• Checksum과 데이터를 더했을 때, 모든 비트가 1이면 정상으로 판단한다.

Urgent Pointer

• 긴급 포인터
• URG 플래그가 1이라면 수신 측은 이 포인터가 가리키고 있는 데이터를 우선 처리한다.

TCP Options

• 약 30개 정도의 TCP 옵션을 설정할 수 있다.
• 대표적으로 Window 필드의 사이즈를 늘릴 수 있는 옵션이 있다.

3-Way Handshake

• 데이터를 보내기 전에 연결을 확립하기 위해 패킷 요청을 세번 교환하는 것을 말한다.
• TCP Flags를 이용하여 패킷을 교환한다.

UDP( User Datagram Protocol )

• 데이터를 효율적으로 빠르게 보낼 때 사용한다.
• 비연결형 통신이기 때문에 3-Way Handshake 과정이 존재하지 않는다.
  • 신뢰성과 정확성은 떨어지나 효율이 증가한다.

UDP 헤더

TCP는 신뢰성 있는 데이터 통신을 위해 설계된 전송 계층 프로토콜이다. 

TCP는 연결지향 방식의 신뢰성 있는 프로토콜로, 데이터를 정확하게, 순서대로, 중복 없이 전달하는 데 초점을 맞춘다.

• 통신 전 반드시 연결 설정이 필요하다. ( 연결 지향 ) 3-way handshake
• 손실/중복/순서 오류 방지 및 재전송 기능을 포함한다. ( 신뢰성 보장 )
• 송신 측이 수신 측의 처리 속도를 초과하지 않도록 조절한다. ( 흐름 제어 )
• 네트워크 과부하를 방지하기 위한 제어 알고리즘이 존재한다. ( 혼잡 제어 )
• 양방향 데이터 전송이 가능하다. ( 전이중 통신 )
• 패킷이 순서대로 도착하게 정렬되고 재조립한다. ( 패킷 순서 보장 )

🔷 TCP 헤더 구조

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 ) 순서

1. 서버는 접속 요청을 받기 위한 소켓을 연다. ( Listen )
2. 클라이언트는 소켓을 만들고, 서버에 접속을 요청한다. ( Connect )
3. 서버는 접속 요청을 받아서 클라이언트와 통신할 소켓을 따로 만든다. ( Accept )
4. 소켓을 통해 서로 데이터를 주고 받는다. ( Send & Receive 반복 )
5. 통신을 마치면 소켓을 닫는다. ( 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 패킷, 종종 세그먼트라고 불리는 것은 다음과 같은 주요 부분으로 구성된다.

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

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

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