HTTP의 특징,webSocket의 특징

HTTP의 특징

 

• Request <-> Response 구조

Request가 있어야만 Response가 존재할 수 있기 때문에 리퀘스트 리스폰스 구조라고 합니다. 만약 서버가 HTTP 응답을 보내야 하는데 요청이 없다면 어디로 응답을 보내야 할지 알 수 없습니다. 간단하게 말해 요청(Request)이 없다면 응답(Response)도 없다고 이해할 수 있습니다.

• 비 연결성

이 구조는 비 연결성을 가지고 있는데, 하나의 요청을 보내고 하나의 응답을 받으면 그 연결이 끝난다는 것을 의미합니다. 요청 후 응답을 보낸 후 새로운 요청을 보낼 때마다 새로운 연결이 생성됩니다.

(요청---응답) => (요청)     (응답)

장점: 연결을 유지하지 않기 때문에 리소스 소모가 적고, 따라서 처리가 빠릅니다.

• Stateless (무상태)

서버가 클라이언트의 상태를 저장하지 않는 것을 의미합니다. HTTP는 기본적으로 상태를 저장하지 않기 때문에, 매번 새로운 요청으로 처리합니다. 이를 무상태(stateless)라고 합니다. 하지만 세션, 쿠키, 데이터베이스 등을 통해 상태를 임시로 저장하여 사용자 경험을 개선할 수 있습니다.

• HTTP 헤더

헤더에는 메시지에 필요한 모든 부가 정보가 들어 있으며, 추가하고 싶은 내용도 자유롭게 추가할 수 있습니다.

 

1.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: 본문 내용의 압축 방식 지정. 본문의 데이터 길이가 나와서 브라우저가 해석할 때 사용됩니다.

chunked: 본문의 내용이 동적으로 생성되어 길이를 모르기 때문에 나눠서 보낸다는 의미

Upgrade: 프로토콜 변경 시 사용 (예: HTTP/2.0)

Via: 중계(프록시) 서버의 이름, 버전, 호스트명

Content-Encoding: 본문의 리소스 압축 방식 (Transfer-Encoding과는 다름)

Content-type: 본문의 미디어 타입 (예: application/json, text/html)

Content-Length: 본문의 길이

Content-language: 본문을 이해하는 데 가장 적절한 언어 (예: ko). 한국 사이트여도 본문을 이해하는 데 영어가 제일 적절하면 영어로 지정됩니다.

Expires: 자원의 만료 일자

Allow: 사용 가능한 HTTP 메소드 (예: GET, HEAD, POST)

Last-Modified: 최근에 수정된 날짜

ETag: 캐시 업데이트 정보를 위한 임의의 식별 숫자

Connection: 클라이언트와 서버의 연결 방식 설정 (HTTP/1.1은 keep-alive가 기본)

 

2.Request/Response Header

 

request header는 웹브라우저가 웹서버에 요청하는 것을 텍스트로 변환한 메시지들입니다.

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

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

User-agent: 클라이언트 프로그램 정보 (예: Mozilla/4.0, Windows NT5.1)

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

Accept: 클라이언트가 처리 가능한 미디어 타입 종류 나열 (예: /, application/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' -> 자기 도메인에서만 가져옴)

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

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

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

Cookie: 쿠키 값 key-value로 표현됨 (예: attr1=value1; attr2=value2)

response header는 웹브라우저가 요청한 메시지에 대한 응답으로 상태(예: 200, 400 등), 메시지, 그리고 요청한 응답 값들이 본문(body)에 담겨 있습니다.

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

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

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

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

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

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

 

3.Entity Header

• HTTP는 OSI 7계층 중 하나인 응용 계층(Application Layer)에서 동작하는 프로토콜이며, 전송 계층(Transport Layer)의 위에서 동작합니다.
• 전송 계층의 대표적인 프로토콜은 TCP와 UDP가 있는데, HTTP는 TCP와 UDP 중 하나의 연결을 통해 동작합니다. 따라서, HTTP는 TCP/UDP 프로토콜이 없다면 동작이 불가합니다.
• TCP 프로토콜은 연결 지향성입니다. TCP는 데이터 교환을 하기 위해서는 무조건 연결을 해야 합니다.

• 3-Way Handshake 방식
  • TCP에서 데이터를 전송하기 전에 연결을 설정하기 위해 사용하는 방식입니다. SYN, SYN-ACK, ACK 세 단계로 이루어져 있습니다.

 

webSocket의 특징

 

 

• 실시간 통신
  • WebSocket은 지속적으로 메시지를 교환할 수 있어, 실시간으로 데이터를 주고받는 것이 가능합니다. 따라서 채팅, 주식 거래, 게임 등과 같은 실시간 응답이 필요한 애플리케이션에서 유용합니다.
• 양방향 통신 (Full-Duplex)
  • 클라이언트에서 서버로, 서버에서 클라이언트로 모두 자유롭게 메시지를 보낼 수 있는 양방향 통신을 지원합니다. 이를 통해 클라이언트와 서버가 상호작용하며 데이터를 주고받을 수 있습니다.
• 지속적 연결
  • WebSocket은 한 번 연결이 설정되면 TCP와 같이 지속적으로 연결이 유지되며, 연결이 끊어지지 않는 한 추가적인 핸드셰이크 없이 양방향으로 데이터를 주고받을 수 있습니다. 이러한 특징은 HTTP의 비연결성과 대조적입니다.
• 낮은 오버헤드
  • 데이터 패킷의 크기가 작기 때문에 HTTP와 비교했을 때 데이터 패킷을 주고받을 때 오버헤드가 적습니다. 이로 인해 데이터 전송 시 효율적으로 교환이 가능하여 대역폭을 절약할 수 있습니다.
• HTTP와의 호환성
  • WebSocket은 초기 연결 설정 시 HTTP 프로토콜을 사용하여 핸드셰이크를 수행한 후, 연결이 성립되면 WebSocket 프로토콜로 전환합니다. 이를 통해 기존 HTTP 기반 웹 애플리케이션과의 호환성을 유지하면서도, 더 효율적으로 데이터를 교환할 수 있습니다.