[Web] HTTP, HTTPS, HTTP 버전

HTTP

• Hyper Text Transfer Protocol의 약어로 WWW(World Wide Web)에 내재된 프로토콜이다.
• 인터넷에서 자원(파일, 이미지, 비디오)을 교환하는 프로토콜(약속, 규칙)
• ∴ HTTP는 인터넷에서 클라이언트와 웹 서버간 통신(데이터를 주고 받음)을 위한 프로토콜 중 하나
• 기본 포트 80

• 하이퍼텍스트 문서를 표현하기 위한 텍스트 형식의 마크업 언어가 HTML(하이퍼 텍스트 마크업 언어)
• 문서 같은 것을 교환하기 위한 간단한 프로토콜이 HTTP(하이퍼텍스트 전송 프로토콜)
• 문서를 디스플레이하기 위한 클라이언트가 WWW(첫번째 브라우저)

CORS(Corss-Origin Resource Sharing)

• 보안상의 이유로 브라우저들이 다른 도메인에게 XHR 요청 보내는 것을 제한할 수 있다.
• CORS는 추가 HTTP 헤더를 사용하여, 한 웹 애플리케이션이 다른 출처(도메인, 프로토콜, 포트)의 자원에 접근할 수 있는 권한을 부여하도록 브라우저에게 알려주는 체제이다.

CORB(Corss Origin Read Blocking)

• CORS를 허용했더라도, POST, PUT, DELETE 요청에서 json을 전송하는 경우 요청이 차단된다.
• 이 경우에는 json 대신 www-form-urlencoded형식으로 데이터를 보내면 된다.

 

HTTPS

• HyperText Transfer Protocol over Secure Socket Layer 의 약어로 HTTP의 보안이 강화된 버전이다. HTTP over TLS, HTTP over SSL, HTTP Secure 라고도 불린다.
• 기본적인 TCP/IP 스택을 통해 HTTP를 전송하는 대신에 추가적인 암호화 전송 계층인 SSL을 만들었다. SSL은 서버와 클라이언트 간에 교환된 메시지 인증을 암호화하고 보장한다. 표준화가되어 TLS가 되었다.
• HTTP는 소켓 통신에서 일반 텍스트를 이용하는 대신에, SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다. 따라서 데이터의 적절한 보호를 보장한다.
• 기본 포트 443

 

HTTP 버전

구분	내용	특징
HTTP/0.9	매우 제한적 1. 경로로 가능한 메서드는 GET이 유일     → GET /home.html 2. HTTP 헤더가 없음 → HTML 파일만 전송 가능 3. 상태, 오류 코드도 없음     → 문제가 발생한 경우 HTML 파일에 문제 설명을 첨부하여 보내짐)	초기 버전, 원-라인 프로토콜
HTTP/1.0	브라우저와 서버 모두 융통성을 가지도록 확장 1. 버전 정보가 전송     → GET /home.html HTTP/1.0 2. 상태 코드가 응답 시작 부분에 붙어 전송     → 성공/실패를 알 수 있어 결과에 대한 동작을 할 수 있어짐 3. HTTP 헤더 개념 도입    → 요청과 응답시 메타 데이터 전송을 허용하고 프로토콜을 유연하고 확장 가능하도록 만듦     → Content-Type : HTML 파일 외에 다른 문서들을 전송 가능	확장성 만들기
HTTP/1.1(표준 프로토콜)	모호함을 명확히하고 많은 개선 사항을 도입 1. 개선된 지속 커넥션      → 트랜잭션마다 커넥션을 맺는다면 '커넥션 맺는 시간 + slow start'지연발생, 이런 지연을 방지.     → HTTP/1.0의 keep-alive와 달리 별도 설정을 하지 않는 한, 모든 커넥션을 지속 커넥션으로 취급한다. 트랜잭션을 끊기 위해서는 'Connection: close'를 포함해야 한다.     → 클라이언트, 서버에 대해 별도의 지속 커넥션을 맺고 관리해야 한다. 병렬 커넥션 커넥션의 지연 시간을 겹치게 하여 총 지연 시간을 줄임 여러 개의 TCP 커넥션을 통한 동시 HTTP 요청 지속 커넥션 커넥션을 유지하여 요청이 들어올 때 커넥션 재사용 파이프라인 커넥션 실행중인 명령이 끝나기 전에 다른 명령의 실행을 시작 커뮤니케이션 지연시간을 줄임 공유 TCP 커넥션을 통한 병렬 HTTP 요청 다중 커넥션 요청과 응답들에 대한 중재 2. 청크된 응답 지원     → 많은 양의 데이터가 요청이 완전히 처리되기 전까지 응답의 전체 크기를 알지 못하는 경우 유용 3. 추가적인 캐시 제어 매커니즘 도입     → 원본 서버의 리소스에 비해 오래되거나 유효하지 않을 가능성이 있기 때문에 중요.     → 최신 캐시라고 간주되면 클라이언트에 바로 전송     → 유효성 검증 : 'Cache-control: max-age=N' 헤더가 설정된 경우 유효 수명은 N, 해당 헤더가 없다면, Expires 헤더가 있는지 검사, 있다면, 그 값에서 Date 헤더의 값을 뺀 결과가 유효 수명, 서버가 명시적으로 유효성을 지정하지 않으면, Last-Modified 헤더를 찾는다. 있다면 캐시의 유효 수명은 Date헤더 값에서 Last-modifed 헤더값을 뺀 값을 10으로 나눈 결과가 된다. 4. 언어, 인코딩 혹은 타입을 포함한 컨텐츠 협상 도입     → 클라이언트와 서버로 하여금 교환하려는 가장 적합한 컨텐츠에 대한 동의를 가능케 함 5. Host 헤더     →동일 IP 주소에 다른 도메인을 호스트하는 기능이 서버 코로케이션을 가능케 함	표준 프로토콜 HOL(Head Of Line) Blocking-특정응답 지연 RTT(Round Trip Time)증가 헤비한 Header 구조(특히 쿠키 때문)
HTTP/2	HTTP/1.1 버전과 몇가지 근본적 차이점을 가짐, 성능과 속도면에서 월등 1. 텍스트 프로토콜보단 이진 프로토콜     → 텍스트 명령을 네트워크를 통해 전송 전에 바이너리로 변환     → 컴팩트한 명령 표현    → 네트워크의 공간 절약화, 오버 헤드가 적음, 네트워크 대기 시간 감소 및 처리량 향상     → 응답 분할 공격과 같은 텍스트 특성 관련 보안 문제 제거 2. Multiplexed Streams     → 한 커넥션에 여러개의 메세지를 동시에 주고 받을 수 있음      → 단일 TCP 연결을 통해 여러 데이터 요청을 병렬로 보냄, 추가 왕복 시간 (RTT)가 줄어들어 최적화 없이 빠르게 로드할 수 있고, 도메인 샤딩이 필요하지 않음.     → 병렬 요청이 동일한 커넥션 상에서 다루어질 수 있는 다중화 프로토콜.     → 순서를 제거해주고 HTTP/1.x 프로토콜의 제약사항을 막아줌 3. Header Compression     → Header 정보를 HPACK 압축방식을 이용하여 압축전송전송된 데이터의 분명한 중복과 오버헤드를 제거     → 연속된 요청 사이의 매우 유사한 내용으로 존재하는 헤더들을 압축시킴 4. Server Push     → 서버에 사전에 클라이언트 캐시를 서버 푸시라고 불리는 매커니즘에 의해 필요하게될 데이터로 채워넣도록 허용함으로써 리소스를 재사용할 수 있고, 푸시된 자원을 다중화할 수 있으며, 우선순위를 지정할 수 있다.	페이지 로딩 속도 향상 요청 헤더 압축 이진 프로토콜 HTTP/2 서버 푸시 단일 TCP 연결을 통해 요구 다중화 파이프 라인을 요구하는 HOL 차단 (Head-of-Line) - 패키지 차단 브라우저 호환성이 좋음
차세대 HTTP/2	새로운 확장성(확장성의 발전) 1. Alt-Svc : 영리한 CDN 매커니즘     → 신분 증명의 개념과 주어진 자원의 위치를 분리 2. Client_hints 도입     → 브라우저 혹은 클라이언트가 요구사항이나 서버의 하드웨어 제약사항에 관한 정보를사전에 미리 주고 받을 수 있게 됨 3. Cookie 내에 보안 관련 접두사 도입     → 보안 쿠키가 변경되지 않았다는 것을 보장
HTTP/3	QUIC 사용 - UDP 1. QUIC라는 프로토콜위에서 돌아가는 HTTP 2. 스트림은 동일 QUIC 연결을 공유하므로 새 스트림을 만들 때 추가적인 핸드쉐이크나 슬로우 스타트가 필요하지 않음 3. QUIC 스트림은 독립적으로 전달되어 어떤 스트림에 패킷 손실이 있는 경우에도 다른 스트림에 영향이 없음.     → QUIC 패킷이 UDP 데이터그램 위에 캡슐화되어 있기 때문 4. QUIC는 TCP의 전형적인 3방향 핸드쉐이크와 TLS 1.3의 핸드쉐이크를 결합한다. 5. HTTP/2에 있는 프레임, 스트림, ,메시지 구조와 기술들은 그대로 승계, 명칭만 HQframe, QPACK등으로 변경	QUIC UDP 선택(HTTP/1과, HTTP/2는 TCP를 자신들의 트랜스포트로 사용)

• 슬로우 스타트(Slow Start)
  • 합 증가/곱 감소 방식(AIMD)은 처음에 전송 속도를 올리는데 걸리는 시간이 너무 길다.
    • 처음에 패킷을 하나씩 보내고 문제없이 도착하면 윈도우 크기를 1씩 증가시켜가며 전송한다. 만약 전송에 실패하면 윈도우 크기를 반으로 줄인다.
    • 윈도우 크기를 너무 조금씩 늘리기 때문에 네트워크의 모든 대역을 활용하여 제대로 된 속도로 통신하기 까지 시간이 너무 오래 걸린다.
  • 느린 시작방식은 합 증가/곱 감소 방식과 마찬가지로 패킷을 하나씩 보내는 것부터 시작하지만 패킷이 문제 없이 도착하면 각각의 ACK 패킷마다 창 크기를 1씩 늘려 한 주기가 지나면 창 크기가 2배로 된다. 따라서 전송 속도가 지수 함수 꼴로 증가한다.
  • 대신에 혼잡 현상이 발생하면 창 크기를 1로 떨어뜨린다. 한번 혼잡현상이 발생하고 나면 네트워크 수용량을 예상할 수 있으므로 혼잡 현상이 발생했던 창 크기의 절반(임계점)까지는 이전처럼 지수 함수 꼴로 창 크기를 증가시키고 그 이후부터는 완만하게 1씩 증가시킨다.
  • TCP 동작 방식이 처음에 최대한 보낼 수 있는 만큼의 패킷을 보내는 것으로 시작하고, 느린 시작은 이와 달리 창 크기를 1에서부터 시작하여 지수함수 꼴로 증가시켜가면서 네트워크의 수용량을 감지한다. 합 증가/곱 감소 방식보다 더 효율적인 방법이지만 혼잡한 상황이 된 경우에 타임아웃 될 때까지 기다리는 동안 큰 시간의 공백이 있다.
• 도메인 샤딩(Domain sharding)
  • resource 를 여러 개의 domain 으로 나누어 저장하여, page load time 을 향상시키는 일종의 트릭 혹은 방법이다. 여러 개의 domain 으로 나누어진 리소스를 다운받기 때문에 browser 는 더 많은 리소스를 한번에 더 많이 받을 수 있다.
• QUIC(Quick UDP Internet Connections)
  • TCP를 사용하는 연결 지향 웹 애플리케이션의 성능을 개선
    • UDP를 경유하여 2개의 종단점 간 수많은 다중화 연결을 확립함으로써 이를 달성
    • HTTP/2의 다중화 연결과 협력하여 동작하며 여러 데이터 스트림들이 개별적으로 모든 종단점에 도달할 수 있고 다른 스트림을 수반하는 패킷 손실에 독립적이다.
      • 반면, TCP로 호스팅된다면, 어떤 TCP 패킷이라도 지연되거나 소실될 경우 모든 다중화 스트림에 대해 HOL-Blocking 지연 문제가 발생
  • 혼잡 회피를 위해 각 방향에서 발생할 수 있는 연결 및 전송 레이턴시와 대역폭을 감소
  • 두 종단점의 혼잡 제어 알고리즘을 커널 공간이 아닌 사용자 공간 안으로 배치시킴으로써 알고리즘을 더 빠르게 개선시킬 수 있다.
  • 오류 예측 시 전방 오류 정정(FEC)와 함께 성능을 추가적으로 개선시킬 수 있다.
    • FEC() : 보내는 사람이 전송에 앞서 오류 정정 코드를 사용하여 데이터를 인코딩, 송신측에서 문자나 프레임에 오류 검출을 위한 확장 데이터를 추가해 전송해 수신측에서 이를 활용해 데이터에 오류가 발생했는지 검출하고 수정한다.
    • ARQ(후방 오류 정정) : 수신되는 모든 데이터 블록은 오류 정정을 사용하여 검사되며 검사가 실패하면 데이터 재전송을 요청, 실시간 처리에서는 곤란함, 패리티 검사, CRC 등을 이용해 오류 검출

UDP와 TCP 비교

TCP는 데이터를 주고 받을 양단 간에 먼저 연결을 설정(연결시 3Way-Handshake, 끊을 때 4Way-Handshake)하고 설정된 연결을 통해 양방향으로 데이터를 전송하지만,
UDP는 연결을 설정하지 않고 수신자가 데이터를 받을 준비를 확인하는 단계를 거치지 않고 단방향으로 정보를 전송한다.

• 신뢰성 - TCP는 메시지 수신을 확인하지만 UDP는 수신자가 메시지를 수신했는지 확인할 수 없다.
• 순서 정렬 - TCP에서는 메시지가 보내진 순서를 보장하기 위해 재조립하지만 UDP는 메시지 도착 순서를 예측할 수 없다.
• 부하 - UDP가 TCP보다 속도가 일반적으로 빠르고 오버헤드가 적다.

 

참고

• developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
• lalwr.blogspot.com/2019/01/http1-vs-http2.html
• goldfishhead.tistory.com/26
• velog.io/@leeinae/HTTP-Connection%EC%9D%98-%EA%B4%80%EB%A6%AC-TCP-%EC%A7%80%EC%97%B0-%EB%B0%A9%EC%A7%80
• developer.mozilla.org/ko/docs/Web/HTTP/Caching
• ko.wikipedia.org/wiki/%EC%82%AC%EC%9A%A9%EC%9E%90_%EB%8D%B0%EC%9D%B4%ED%84%B0%EA%B7%B8%EB%9E%A8_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C
• ko.wikipedia.org/wiki/QUIC
• ko.wikipedia.org/wiki/%EC%98%A4%EB%A5%98_%EA%B2%80%EC%B6%9C_%EC%A0%95%EC%A0%95
• velog.io/@mu1616/TCPIP-%ED%98%BC%EC%9E%A1-%EC%A0%9C%EC%96%B4
• www.zerocho.com/category/NodeJS/post/5a6c347382ee09001b91fb6a
• developer.mozilla.org/ko/docs/Web/HTTP/CORS