2. HTTP, TCP, 웹소켓

728x90

TCP가 중요함. 웹소켓은 TCP를 설명하기 위해 가져온 것뿐

01. HTTP (Hyper Text Transfer Protocol) 와 TCP (Transmission Control Protocol)

1. http 프로토콜의 특징

1) Request <-> Response 구조 & 비연결성

Request가 없으면 Response도 없습니다.

Request가 생기면 연결하고 Response 후 끊어짐
연결을 유지하지 않기때문에 많은 트래픽을 빠르게 처리가능합니다.(연결을 위해 불필요한 리소스 사용안함)

2) Stateless (무상태)

이전의 데이터를 저장하지 않음
매번 새로운 요청을 처리

세션, 쿠키 등으로 해당 요청에 대한 정보를 임의로 저장해서 처리하곤 합니다. (로그인 상태 유지 등)

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

해더

메세지에 필요한 모든 부가 정보(토큰, 사용자 위치, 서버위치, 메시지를 위한 정보 등)가 들어있음
넣고싶은 내용 아무거나 추가 가능
헤더는 General Header, Reqeust/ Response Header, Entity Header로 구성되 있음

참고 내용 : General Header, Reqeust/ Response Header의 키값

General Header의 키값

● Date : 현재시간 (Sat, 23 Mat 2019 GMT)

● 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 : 프로토콜 변경시 사용 ex) HTTP/2.0
● Via : 중계(프록시)서버의 이름, 버전, 호스트명
● Content-Encoding : 본문의 리소스 압축 방식 (transfer-encoding은 body 자체이므로 다름)
● Content-type : 본문의 미디어 타입(MIME) ex) application/json, text/html
● Content-Length : 본문의 길이
● Content-language : 본문을 이해하는데 가장 적절한 언어 ex) ko
○ 한국사이트여도 본문을 이해하는데 영어가 제일 적절하면 영어로 지정된다.
● Expires : 자원의 만료 일자
● Allow : 사용이 가능한 HTTP 메소드 방식 ex) GET, HEAD, POST
● Last-Modified : 최근에 수정된 날짜
● ETag : 캐시 업데이트 정보를 위한 임의의 식별 숫자
● Connection : 클라이언트와 서버의 연결 방식 설정 HTTP/1.1은 kepp-alive 로 연결 유지하는게 디폴트.

Reqeust/ Response Header의 키값

● request header form는 웹브라우저가 웹서버에 요청하는 것을 텍스트로 변환한 메시지들이다.
○ Request Line : 어떤 웹서버로 접속(Host 부분)해서, 어떠한 방식(HTTP/1.1)으로, 어떠한 메소드(GET)를 통해 무엇을(/doc/test/.html) 요청했는지에 대한 메시지가 담겨있다.

■ GET /test.html http 1.1
○ Host : 요청하려는 서버 호스트 이름과 포트번호
○ User-agent : 클라이언트 프로그램 정보 ex) Mozilla/4.0, Windows NT5.1
■ 이 정보를 통해서 서버는 클라이언트 프로그램(브라우저)에 맞는 최적의 데이터를 보내줄 수 있다.
○ Referer : 바로 직전에 머물렀던 웹 링크 주소(해당 요청을 할 수 있게된 페이지)
○ Accept : 클라이언트가 처리 가능한 미디어 타입 종류 나열 ex) */* - 모든 타입 처리 가능, application/json - json데이터 처리 가능.
○ Accept-charset : 클라이언트가 지원가능한 문자열 인코딩 방식
○ Accept-language : 클라이언트가 지원가능한 언어 나열
○ Accept-encoding : 클라이언트가 해석가능한 압축 방식 지정 ex) gzip, deflate
○ 압축이 되어있다면 content-length와 content-encoding으로 압축을 해제한다.
○ Content-location : 해당 개체의 실제 위치
○ Content-disposition : 응답 메세지를 브라우저가 어떻게 처리할지 알려줌. ex) inline, attachment; filename='jeong-pro.xlsx'
○ Content-Security-Policy : 다른 외부 파일을 불러오는 경우 차단할 리소스와 불러올 리소스 명시ex) default-src 'self' -> 자기 도메인에서만 가져옴
■ ex) default-src 'none' -> 외부파일은 가져올 수 없음
■ ex) default-src https -> https로만 파일을 가져옴
○ If-Modified-Since : 여기에 쓰여진 시간 이후로 변경된 리소스 취득. 페이지가 수정되었으면 최신 페이지로 교체하기 위해 사용된다.
○ Authorization : 인증 토큰을 서버로 보낼 때 쓰이는 헤더
○ Origin : 서버로 Post 요청을 보낼 때 요청이 어느 주소에서 시작되었는지 나타내는 값
■ 이 값으로 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 난다.
Cookie : 쿠기 값 key-value로 표현된다. ex) attr1=value1; attr2=value2
● response header form는웹브라우저가 요청한 메시지에 대해서 status 즉 성공했는지 여부(202, 400 등), 메시지, 그리고 요청한 응답 값들이 body에 담겨있다.
○ Location : 301, 302 상태코드일 때만 볼 수 있는 헤더로 서버의 응답이 다른 곳에 있다고 알려주면서 해당 위치(URI)를 지정한다.
○ Server : 웹서버의 종류 ex) nginx
○ Age : max-age 시간내에서 얼마나 흘렀는지 초 단위로 알려주는 값
○ Referrer-policy : 서버 referrer 정책을 알려주는 값 ex) origin, no-referrer, unsafe-url
○ WWW-Authenticate : 사용자 인증이 필요한 자원을 요구할 시, 서버가 제공하는 인증 방식
○ Proxy-Authenticate : 요청한 서버가 프록시 서버인 경우 유저 인증을 위한 값
○ 응답 상태 코드

전송계층의 대표적인 프로토콜은 TCP/ UDP가 있습니다.
HTTP는 TCP/UDP 프로토콜이 없으면 동작이 불가능합니다.

2. TCP

HTTP는 비연결성이지만 TCP는 연결지향성이다.
TCP는 데이터교환을 할 때 무조건 연결을 가집니다.

TCP는 데이터교환을 할 때 무조건 연결을 가집니다.
HTTP의 Req ↔ Res 가 발생할때 밑에서(4계층) TCP 연결이 이뤄진다.
TCP는 3-handshake 라고하는 연결 과정을 가지고 있다.(끊을 때는 4-handshake)

3-handshake 추가 정보

※HTTP는 비연결성이지만 TCP는 연결지향성이라 하지만 이건 HTTP 1.1 버전 얘기이고
HTTP 2에서는 이전 연결을 재사용 가능합니다.
HTTP 3은 UDP에서 연결합니다(TCP보다 빠름)

TCP통신

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

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

02. 웹소켓 (Websocket)

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

1. 웹소켓의 주요 특징

실시간 통신
양방향 통신 (Full-Duplex)
지속적 연결
낮은 오버헤드
   HTTP나 TCP보다 헤더가 작음
   연결 이후 데이터 교환할때의 websocket의 헤더는 극도로 간소화되어 있습니다.
   FIN 비트, Opcode, Mask 비트, Payload 길이 정보가 포함
HTTP와의 호환성
   HTTP를 통해 작동하기에 기존 웹 인프라에 웹켓을 얹어 실시간 통신을 위해 사용합니다.
   웹소켓은 HTTP연결을 통해 초기화되고(초기세팅) 그 이후로 전이중 통신(양방향통신) 채널로 전환됩니다.
   TCP에서 3-handshake를 통해연결하듯 웹소켓도 연결을 위한 handshake가 따로 있습니다.

각 프로토콜의 헤더 비교

HTTP >TCP > websocket

1. 보통의 HTTP Request Header

GET /data HTTP/1.1
Host: http://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

일부만 잘라온거지만 길다.
요청이 간 만큼의 응답을 받습니다.(항상 헤더가 길다)

2. 연결 이후 데이터 교환할때의 websocket의 헤더

  0x81 0x05

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

※참고

Opcode : 웹소켓에 데이터를 보낼 때 데이터의 종류를 설명하는 코드
FIN 비트 : 연결을 시작하고 연결을 끊는 데이터의 정보

3. 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!"

전송 속도

속도는 일반적으로 더 낮은 레벨에서(4계층) 연결을 맺는 TCP가 가장 빠름.
놀라운 "성능 최적화" 때문에 TCP 프로토콜이 대부분 빠르게 보인다.

※ 요약

◆ HTTP와 TCP의 특징 이해

HTTP는 **비연결성(stateless)**과 요청-응답 구조를 가지며, 매 요청마다 연결이 새로 설정됩니다.
TCP는 HTTP의 하위 프로토콜로, 연결 지향적이고 데이터 교환 시 항상 연결을 유지하며, 3-way handshake를 통해 연결을 설정합니다.
HTTP/2는 연결 재사용을 지원하며, HTTP/3는 UDP 기반에서 동작해 더 빠른 통신을 제공합니다.

◆ 웹소켓의 특징과 동작 원리 이해

웹소켓은 HTTP 위에서 동작하며, 초기에는 HTTP로 연결을 설정한 후 지속적 연결을 유지합니다.
주요 특징:
- 실시간 양방향 통신 (Full-Duplex)
- 헤더 크기가 작아 낮은 오버헤드
- 기존 HTTP 인프라와 호환성

※ 기억할 것

◆ HTTP와 TCP의 핵심

HTTP는 TCP 위에서 동작한다.
- HTTP의 요청-응답 구조는 TCP 연결을 통해 이루어진다.
- HTTP는 비연결성, TCP는 연결 지향성으로 차이가 있지만, 둘은 협력 관계임.

◆ TCP의 특징

3-way handshake: 연결의 시작
1. 클라이언트 → 서버: 연결 요청(SYN).
2. 서버 → 클라이언트: 승인(SYN + ACK).
3. 클라이언트 → 서버: 요청 수락(ACK).
- 이 과정이 안정적인 데이터 전송의 기초.

◆ 웹소켓의 실시간 통신

웹소켓은 HTTP를 사용해 연결을 초기화한 후 지속적 연결을 유지.
- 웹소켓은 헤더 크기가 작아 데이터 교환 시 오버헤드가 적음.
- 실시간 양방향 통신에 적합.
HTTP와 비교:
- HTTP는 요청-응답마다 연결/해제를 반복.
- 웹소켓은 연결 이후 지속적으로 데이터 송수신 가능.

실시간 통신이 필요한 경우 웹소켓이 적합.
예: 채팅, 게임, 주식 실시간 데이터.

저작자표시

'내일배움 강의 > 강의-게임서버' 카테고리의 다른 글

5. 서버 로직 개발 (0)	2024.12.12
4. 개발 환경 세팅 (2)	2024.12.11
3. 게임 기획해보기 (2)	2024.12.11
1. 게임 개발의 시작 (1)	2024.12.10

Strobus

2. HTTP, TCP, 웹소켓

01. HTTP (Hyper Text Transfer Protocol) 와 TCP (Transmission Control Protocol)

1. http 프로토콜의 특징

1) Request <-> Response 구조 & 비연결성

2) Stateless (무상태)

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

해더

General Header의 키값

Reqeust/ Response Header의 키값

2. TCP

TCP통신

02. 웹소켓 (Websocket)

1. 웹소켓의 주요 특징

각 프로토콜의 헤더 비교

1. 보통의 HTTP Request Header

2. 연결 이후 데이터 교환할때의 websocket의 헤더

3. TCP 패킷의 구조

전송 속도

※ 요약

※ 기억할 것

'내일배움 강의 > 강의-게임서버' 카테고리의 다른 글

티스토리툴바

2. HTTP, TCP, 웹소켓

01. HTTP (Hyper Text Transfer Protocol) 와 TCP (Transmission Control Protocol)

1. http 프로토콜의 특징

1) Request <-> Response 구조 & 비연결성

2) Stateless (무상태)

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

해더

General Header의 키값

Reqeust/ Response Header의 키값

2. TCP

TCP통신

02. 웹소켓 (Websocket)

1. 웹소켓의 주요 특징

각 프로토콜의 헤더 비교

1. 보통의 HTTP Request Header

2. 연결 이후 데이터 교환할때의 websocket의 헤더

3. TCP 패킷의 구조

전송 속도

※ 요약

※ 기억할 것

'내일배움 강의 > 강의-게임서버' 카테고리의 다른 글

관련글

티스토리툴바