1-2 HTTP와 TCP 그리고 웹소켓

 

1. HTTP 구조

1) Request, Response 구조 + 비연결성

Request	↔️	Response
1. Request가 없으면 Response를 보내지 못 한다. Request에는 유저의 정보(송신지 포트 주소)가 있다 서버는 Requset로 부터 온 요청에 대한 Response를 유저의 송신지 포트 주소로 보내주면 된다. 2. 비연결성(연결을 유지하고 있지 않다) 유저의 Request를 서버가 Response로 응답했다면 연결은 끝이 납니다. 연결을 유지하지 않기 때문에 리소스가 적어지고, 처리 속도가 빨라집니다.

 

2) Stateless (무상태)

Request에 따른 Response로 응답하면 연결은 끝난 것 입니다.

 

그 결과,

 

이전 연결, 이후 연결 모두 새로운 연결이 되고,

이전에 일어났던 일(상태)를 저장하고 있지 않아

 

그림에서와 같이 이전에 먹었던 과자를 요청하면,

서버는 응답에 대한 결과를 제공할 수 없습니다.

 

→ 세션, 쿠키, DB로 해당 요청에 대한 정보를 임의로 저장해서 처리한다.

이유 : 좋은 유저 경험을 위해서

 

3) HTTP 메세지 구조

 

Request와 Response에 위와 같은 구조로 메시지가 오고, 나간다.

 

여기에서 우리가 눈여겨 볼 부분은

 

헤더 Header로

 

- 메세지에 필요한 모든 부가 정보

ex) 송수신지 Port 주소, 원하는 내용

 

- 넣고 싶은 내용도 아무거나 추가 가능

(서버는 넣고 싶은 내용을 넣어 보내면 된다)

 

구체적으로 HTTP Header에는 무슨 내용이 있을까?

General Header와 Request/Response Header의 내부 구성을 보기 전

 

General Header와 Request/Response Header는 객체 구조

내부 구성은 Key와 Value의 구성으로 이뤄져 있다.

 

i ) 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 : 캐시의 유효시간을 명시하겠다.
  •  
  • pivate : "브라우저" 같은 특정 사용자 환경에만 저장
  • 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 로 연결 유지하는게 디폴트.

 

ii ) 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 : 요청한 서버가 프록시 서버인 경우 유저 인증을 위한 값
  • 응답 상태 코드

 

 

 

위의 내용은 유저가 서버에게 Request를 요청한 상태에

Request Header에 담겨 있는 Key 이름들이다.

 

아래의 내용은 서버가 유저에게 Response를 응답한 상태에

Response Header에 담겨 있는 Key 이름들이다.

 

 

이렇게, 위와 같이 유저가 서버에 통신을 주고 받을 수 있는 이유는

OSI 7에서 4계층(Transport Layer(전송 계층))이 있기 때문이다.

 

Transport Layer(전송 계층)

HTTP는 7계층의 한 부분으로 HTTP만 존재할 경우 서버에게 요청을 보낼 수 없고, 받을 수도 없습니다. 하지만 4계층(Transport Layer)의 TCP를 통해 통신이 가능해집니다.

 

2. 4계층 전송계층 (Transport Layer) 특징

 

1) 연결지향

- TCP는 데이터 교환을 할 때 무조건 연결을 해야합니다.

 

위와 같이 Source Port와 Destination Port가 존재하고,

 

Sequence Number로 쪼개진 데이터의 순서를 보장하기 때문에

 

연결지향적인 특징을 가진다.

(+ 오류 제어, 혼잡제어도 연결지향적인 특징을 위해 존재합니다)

 

- TCP는 3-handshake(연결 시작을 위해 사용), 4-handshake(연결 종료를 위해 사용)라고

  하는 연결 과정을 가진다.

예외 사항

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

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

 

그래서 TCP 통신은 어떻게 이뤄지는가?

 

양방향 통신 순서

 

1. 서버는 접속 요청을 받기 위한 소켓을 연다 → Listen

 

2. 클라이언트는 소켓을 만들고, 서버에 접속을 요청한다  → Connect

 

3. 서버는 접속 요청을 받아서 클라이언트와 통신할 소켓을 따로 만든다 → Accept

 

4. 소켓을 통해 서로 데이터를 주고 받는다 → Send & Receive (반복)

 

5. 통신을 마치면 소켓을 닫는다. → Close(상대방은 Receive로 인지할 수 있다.)

 

3. 웹 소켓 (Websocket)

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

 

생긴 이유 : "결국 HTTP도 TCP 연결 위에서 이뤄지니깐, HTTP로도 양방향 통신이 이뤄지면 안 되나" 해서

=> Websocket이 생겨나게 됩니다.

 

1) 특징

 

- 실시간 통신 : 웹 소켓은 연결이 활성화된 상태에서 빠르고 지속적인 메시지 교환을 허용한다.

                        이로 인해 어플리케이션은 사용자에게 지연 없는 인터랙션을 제공할 수 있습니다.

 

- 양방향 통신 (Full-Duplex) : 클라이언트와 서버가 동시에 서로에게 메시지를 보낼 수 있다.

                                              이는 한 쪽이 다른 쪽의 메시지를 기다리지 않고도 독립적으로

                                              메시지를 송수신할 수 있음을 의미합니다.

 

- 지속적 연결 : 일단 웹소켓이 수립되면, 그 연결은 클라이언트나 서버가 명시적으로 종료할 때까지 유지 됩니다.

                        이는 호버헤드를 줄이고 빠른 데이터 전송을 가능하게 합니다.

 

- 낮은 오버헤드 : 웹소켓은 데이터 패킷의 헤더가 매우 작기 때문에 오버헤드가 낮습니다.

                            이는 효율적인 네트워크 자원 사용을 가능하게 합니다.

 

- HTTP와의 호환 : 웹소켓은 HTTP 포트(80과 443)를 통해 작동하기 때문에 기존 웹 인프라와 잘 통합됩니다.

                              웹소켓 연결은 HTTP 연결을 통해 초기화되며, 이후 전이중 통신 채널로 전환됩니다.

 

2)  Web Socket의 헤더

 

  0x81 0x05 

 

16진수로 된 2개의 값이 존재합니다.

하지만 내부에는 Pin Bit(연결 시작, 연결 종료), OP Code(데이터 종류 설명),

Mask Bit, Pay Load의 길이 정보 등 많은 정보가 내포 돼 있습니다.