나한나한나한나

HTTP란

HTTP는 Hypertext Transfer Protocol의 약자로, 웹에서 정보를 전송하기 위한 프로토콜입니다. 

프로토콜이 뭐임?

 

프로토콜은 컴퓨터나 전자 기기들이 서로 통신하기 위한 규칙이나 표준을 말합니다. 쉽게 말해, 프로토콜은 기기들이 "대화"하는 방법을 정의합니다.

 

프로토콜의 주요 특징:

1. 규칙 정의: 데이터를 어떻게 주고받을지, 어떤 형식으로 보낼지 등을 정합니다.
2. 표준화: 모든 참여자가 같은 "언어"를 사용하도록 합니다.
3. 에러 처리: 통신 중 발생할 수 있는 문제를 어떻게 다룰지 정합니다.
4. 보안: 데이터를 안전하게 전송하는 방법을 포함할 수 있습니다.

예시:

• HTTP: 웹 브라우저와 서버 간의 통신
• SMTP: 이메일 전송
• TCP/IP: 인터넷 기반 통신의 기본
• Bluetooth: 근거리 무선 통신

1. client-server 모델: 웹 브라우저(클라이언트)와 웹 서버 간의 통신을 담당합니다.
2. request-response 구조: 클라이언트가 요청을 보내면 서버가 응답합니다.
3. 상태 비저장(Stateless): 각 요청은 독립적으로 처리됩니다.
4. 텍스트 기반: 요청과 응답은 사람이 읽을 수 있는 형태입니다.
5. 다양한 메서드: GET, POST, PUT, DELETE 등 여러 종류의 요청 방식을 지원합니다.
6. HTTPS: 보안이 강화된 버전으로, 데이터를 암호화하여 전송합니다.

---

HTTP 1.0과 HTTP1.1

HTTP 1.0의 문제점:

1. 연결 비지속성: 매 요청마다 새로운 TCP 연결을 열고 닫아야 했습니다.
2. 헤더 중복: 매 요청마다 동일한 헤더 정보를 반복해서 전송해야 했습니다.
3. 단일 요청/응답: 하나의 연결에서 하나의 요청과 응답만 처리할 수 있었습니다.
4. 캐시 제어 기능 부족: 효율적인 캐싱 메커니즘이 없었습니다.

HTTP 1.1의 개선사항:

1. 지속 연결(Persistent Connections):
   • 여러 요청을 하나의 TCP 연결로 처리할 수 있게 되어 네트워크 효율성이 향상되었습니다.

     

2. 파이프라이닝(Pipelining):
   • 응답을 기다리지 않고 여러 요청을 연속해서 보낼 수 있게 되었습니다.

     

3. 호스트 헤더:
   • 동일 IP 주소에서 여러 도메인을 호스팅할 수 있게 되었습니다.

     

4. 향상된 캐시 제어:
   • ETag, If-None-Match 등의 헤더를 통해 더 효율적인 캐싱이 가능해졌습니다.
     • 클라이언트                                    서버
           |                                                   |
           |  1. GET /resource HTTP/1.1     |
           |----------------------------------------->|
           |                                                   |
           |  2. HTTP/1.1 200 OK                |
           |     ETag: "123abc"                     |
           |     [리소스 데이터]                     |
           |<-----------------------------------------|
           |                                                   |
           |  (클라이언트가 리소스와 ETag를 캐시)
           |                                                   |
           |  3. GET /resource HTTP/1.1     |
           |     If-None-Match: "123abc"      |
           |----------------------------------------->|
           |                                                   |
           |  4. HTTP/1.1 304 Not Modified |
           |<-----------------------------------------|
           |                                                   |
           |  (클라이언트가 캐시된 리소스 사용)
     • 초기 요청:
       
       클라이언트가 서버에 리소스를 요청합니다.
       
       
       서버 응답:
       
       서버는 요청된 리소스와 함께 ETag를 응답 헤더에 포함하여 보냅니다.
       ETag는 리소스의 특정 버전을 고유하게 식별하는 문자열입니다.
       
       
       후속 요청:
       
       클라이언트가 동일한 리소스를 다시 요청할 때, 이전에 받은 ETag를 If-None-Match 헤더에 포함시켜 보냅니다.
       
       
       서버의 검증:
       
       서버는 If-None-Match 헤더의 ETag 값과 현재 리소스의 ETag를 비교합니다.
       만약 ETag가 일치한다면 (리소스가 변경되지 않았다면):
       
       서버는 304 Not Modified 응답을 보냅니다.
       이 응답에는 리소스 데이터가 포함되지 않습니다.
       
       
       ETag가 일치하지 않는다면 (리소스가 변경되었다면):
       
       서버는 새로운 리소스 데이터와 함께 200 OK 응답을 보냅니다.
       
       
       
       
       클라이언트의 처리:
       
       304 응답을 받으면 클라이언트는 캐시된 리소스를 그대로 사용합니다.
       200 응답을 받으면 새로 받은 리소스로 캐시를 업데이트합니다.
       
       
       
       이 메커니즘의 장점:
       
       대역폭 절약: 변경되지 않은 리소스는 다시 전송되지 않습니다.
       서버 부하 감소: 리소스가 변경되지 않았을 때 전체 리소스를 다시 생성할 필요가 없습니다.
       데이터의 최신성 보장: 리소스가 변경되었을 때만 새로운 데이터를 전송합니다.
       
       이렇게 ETag와 If-None-Match를 사용하면 불필요한 데이터 전송을 줄이고, 캐시의 유효성을 효율적으로 검증할 수 있습니다.
5. 압축 지원:
   • 응답 데이터를 압축하여 전송할 수 있게 되어 대역폭 사용이 감소했습니다.

   • HTTP 1.1에서의 압축 지원은 주로 응답 본문(response body)의 내용을 압축하는 것을 말합니다. 구체적으로 다음과 같은 것들이 압축 대상이 됩니다:

     1. HTML, CSS, JavaScript 파일
        • 웹 페이지의 구조, 스타일, 동작을 정의하는 텍스트 기반 파일들입니다.
     2. JSON, XML 데이터
        • API 응답이나 데이터 교환 형식으로 자주 사용되는 텍스트 기반 데이터입니다.
     3. 일반 텍스트 파일
        • 로그 파일, 문서 등의 텍스트 내용입니다.
     4. SVG 이미지
        • 벡터 그래픽 형식으로, 텍스트 기반이라 압축이 효과적입니다.
     5. 기타 텍스트 기반 미디어 타입
        • 예: 폰트 파일 중 일부 형식 등

     주의할 점:

     • 이미 압축된 형식(예: JPEG, PNG, GIF 이미지, MP3 오디오 등)은 일반적으로 추가 압축의 대상이 되지 않습니다. 이미 효율적으로 압축되어 있어 추가 압축의 효과가 미미하기 때문입니다.
     • 바이너리 파일도 대부분 압축 대상이 되지 않습니다.

     압축 과정:

     1. 클라이언트가 Accept-Encoding 헤더를 통해 지원하는 압축 방식을 서버에 알립니다.
     2. 서버는 지원되는 압축 방식 중 하나를 선택하여 응답 본문을 압축합니다.
     3. 압축된 응답을 전송할 때 서버는 Content-Encoding 헤더를 통해 사용된 압축 방식을 명시합니다.
     4. 클라이언트는 이 정보를 바탕으로 받은 데이터를 압축 해제합니다.

     주로 사용되는 압축 알고리즘은 gzip, deflate, br(Brotli) 등입니다.

     이러한 압축 지원을 통해 네트워크로 전송되는 데이터의 양을 크게 줄일 수 있어, 특히 대역폭이 제한적인 환경에서 웹 성능을 크게 향상시킬 수 있습니다.

6. 범위 요청:
   • 파일의 일부분만 요청할 수 있게 되어 대용량 파일 전송 시 효율성이 증가했습니다.
7. 추가된 메서드:
   • PUT, DELETE, OPTIONS 등 새로운 HTTP 메서드가 추가되었습니다.

이러한 개선사항들로 인해 HTTP 1.1은 1.0에 비해 웹 성능과 효율성이 크게 향상되었습니다.

---

 

HTTP2

HTTP/2는 HTTP/1.1의 성능 제한을 극복하기 위해 설계되었습니다. HTTP/2의 주요 개선 사항은 다음과 같습니다:

1. 멀티플렉싱 (Multiplexing):
   • 하나의 TCP 연결로 여러 요청과 응답을 동시에 처리할 수 있습니다.
   • HTTP/1.1의 HOL(Head-of-Line) 블로킹 문제를 해결합니다.

     

     

2. 헤더 압축 (HPACK):
   • 헤더 정보를 효율적으로 압축하여 중복 전송을 줄입니다.
   • 네트워크 오버헤드를 크게 감소시킵니다.

     

3. 서버 푸시 (Server Push):
   • 클라이언트의 요청 없이도 서버가 리소스를 미리 보낼 수 있습니다.
   • 페이지 로드 시간을 단축시킬 수 있습니다.

     

4. 스트림 우선순위 지정:
   • 리소스의 중요도에 따라 우선순위를 설정할 수 있습니다.
   • 중요한 리소스를 먼저 로드하여 사용자 경험을 개선합니다.

     

5. 바이너리 프로토콜:
   • 텍스트 기반이 아닌 바이너리 형식으로 데이터를 전송합니다.
   • 파싱이 더 빠르고 오류 발생 가능성이 낮아집니다.

     

6. 단일 연결:
   • 도메인당 하나의 연결만으로 모든 요청을 처리할 수 있습니다.
   • 연결 설정에 따른 오버헤드를 줄입니다.
7. 흐름 제어 (Flow Control):
   • 개별 스트림 레벨에서 데이터 흐름을 제어할 수 있습니다.
   • 리소스 사용을 최적화합니다.

 

이러한 개선사항들로 인해 HTTP/2는 다음과 같은 이점을 제공합니다:

• 페이지 로드 시간 단축
• 네트워크 및 서버 리소스의 효율적 사용
• 모바일 환경에서의 성능 향상
• 대역폭 사용 최적화

결과적으로 HTTP/2는 현대 웹의 복잡성과 대량의 리소스 요청을 더 효율적으로 처리할 수 있게 해주어, 전반적인 웹 성능을 크게 향상시킵니다.

---

결론

특징	http1.1	http2
연결	요청마다 새로운 연결 또는 keep-alive	단일 연결로 다중 요청 처리
통신 방식	텍스트 기반	바이너리 프레이밍 계층 사용
요청 처리	순차적 처리	멀티플렉싱 (병렬 처리)
헤더	반복 전송, 압축 없음	HPACK 압축 사용
HOL 블로킹	발생	해결
서버 푸시	지원 안 함	지원
우선순위 설정	지원 안 함	스트림 별 우선순위 설정 가능
프로토콜 협상	필요 없음	ALPN(Application-Layer Protocol Negotiation) 필요
흐름 제어	TCP 수준에서만	스트림 레벨에서 가능
보안	TLS 선택적	TLS 권장 (대부분 브라우저에서 필수)

---

그래서 HTTP2가 킹왕짱 최종병기냐? → NOPE. HTTP3가 있다

근데 아직 점유율은 낮음

• http3는 QUIC을 기반으로 동작(http3는 앱 계층이고, QUIC은 전송 계층이다)
• QUIC은 UDP를 기반으로 하기 때문에 개빠르고, TLS 1.3의 기능을 자체적으로 통합하고 있어서 보안 문제도 없다
  
  • 구글에서 만들었다.
    • 구글에서 일하려면 Brand-New-Next-Generation-King-God Network Protocol 정도는 만들 줄 알아야 한다.
      • 구글에서 일하기는 글렀다.