HTTP & HTTPS

HTTP

---

• HTTP
  • HTTP(Hyper Text Transfer Protocol)란 서버와 클라이언트(웹브라우저) 간의 데이터를 주고 받기 위한 프로토콜이다. 주로 80번 포트를 사용하고 있다. 따라서 HTTP 서버가 80번 포트에서 요청을 기다리고 있으며, 클라이언트는 80번 포트로 요청을 보내게 된다.HTTP는 WWW(World-Wide-Web) 기반에서 세계적인 정보를 공유하는데 큰 역할을 하였다.
• HTTP 구조
  • HTTP는 애플리케이션 계층의 프로토콜로 TCP/IP 에 의해 동작한다.  Stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성된다.

• HTTP 특징
  • Stateless(무상태) - 서버와 클라이언트 연결을 지속하지 않아 서버는 클라이언트를 상태를 저장하지 않는다.
  • connectionless(비연결성) - 클라이언토 요청에 대한 응답 뒤 서버가 클라이언트 서버 간 연결 해제
  • 클라이언트 - 서버 구조 → 클라이언트의 요청이 있을 때, 서버가 응답하는 단반향 통신

HTTP의 발전

---

• HTTP/1.0
  • HTTP/1.0은 연결마다 하나의 요청을 처리하도록 설계
  • 연결마다 요청을 처리하기 때문에 RTT가 증가하는 문제가 발생했습니다. → RTT : 패킷이 도착지에 도달하고 다시 출발지로 돌아오는데 걸리는 왕복시간
• 해결법
  • 이미지 스플리팅
    • 많은 이미지를 합쳐서 하나의 이미지로 만들어 이미지를 표기하는 방법
  • 코드 압축
    • 말그대로 코드를 압축해서 줄바꿈문자, 빈칸을 없애 코드의 크기를 최소화하는 방법
  • 이미지 Base64 인코딩
    • 이미지파일을 64진법의 문자열로 인코딩하여 이미지에 대한 서버에 HTTP 요청을 할 필요가 없도록 만드는 방법
• HTTP/1.1
  • 매번 연결을 하는 것이 아닌 keep-alive을 사용하여 한번 연결을 하면 여러번 송수신할 수 있는 형태로 바뀌었습니다. 하지만, 다수의 컨텐츠를 처리하려면 개수에 비례해 대기 시간이 길어진다는 단점이 있다.
  • HOL blocking
    • 네트워크에서 큐에 존재하는 패킷이 첫번째 패킷에 의해 지연되는 경우의 성능 저하 현상 즉, 컨텐츠 요청 수가 증가하여 생긴 문제점이다
  • 헤더에 많은 데이터가 들어있고 압축이 되지 않아 용량이 큰 헤더 구조를 가지고 있습니다.
• HTTP/2
  • 구글의 네트워크 프로토콜인 SPDY 기반인 HTTP/1.1을 개선하여 지연 시간은 줄이면서 응답시간을 빠르게한 프로토콜입니다.
  • 주요특징으로는 MultiPlexing, 헤더 압축, Server Push, Steam Priority가 있습니다.
    • 멀티 플렉싱
      • 여러 개의 스트림을 사용하여 송수신한다는 의미입니다.
      • 한 스트림 안에 있는 패킷이 손실되도 다른 스트림에는 영향을 미치지 않습니다.
    • 서버 푸시
      • 클라이언트 요청없이 바로 리소스를 푸시하는 것입니다.
      • HTML, CSS, JS 파일을 하나씩 주는 것이 아닌 HTML을 요청하면 서버에 푸시했던 다른 파일들도 클라이언트에게 먼저 주는 것이 하나의 예시입니다.
    • 헤더 압축
      • HTTP/1.1은 헤더가 너무 컸습니다.
      • 이를 해결하기 위해 허프만 코딩이라는 알고리즘을 통해 헤더를 압축하였습니다.
      • 허프만 코딩
        • 문자열을 문자가 나오는 빈도수를 가지고 빈도가 높으면 적은 비트의 수를 사용하고 반도가 적으면 비트 수를 많이 사용하여 비트의 양을 줄이는 알고리즘입니다.

• HTTP/3
  • 이례적으로 TCP를 포기하고 UDP를 기반한 QUIC 프로토콜을 사용한다.
  • 특징
    • 암호화가 프로토콜의 일부 포함
    • 모든 핸드쉐이크가 단일 요청/응답으로 끝남
    • 패킷이 개별 암호화되어 다른 패킷을 기다릴 필요가 없음
    • 통신이 멀티플렉싱되고 HOL Blocking을 극복할 수 있음
    • QUIC는 OS 커널과 독립적이어서 애플리케이션 공간안에서 구현할 수 있어, Context 전환에 의한 오버헤드가 없습니다. //추가적으로 조사~~
    • 서버에 대한 연결을 고유하게 식별하는 식별자가 있어 IP가 바뀌어도 연결을 유지할 수 있다.
    • 즉, HTTP/3는 새로운 연결에 대해 핸드쉐이킹으로 인한 지연 및 패킷 손실이 다른 스트림에 영향을 미치는 것 마지막으로 패킷 손실로 인한 지연으로 부터 자유롭다.
    • 이미 많은 서비스에서 HTTP/3를 지원하고 있다.
      • HTTP/3 → HTTP/2/ + QUIC

HTTPS

---

• HTTPS
  • HTTPS는 하이퍼 텍스트 전송 프로토콜 보안(Hypertext Transfer Protocol Secure)의 약자로 애플리케이션 계층과 전송 계층 사이에 SSL/TLS을 사용해 암호화한 프로토콜입니다.
  • HTTP의 문제점은 서버에서부터 웹브라우저로 전송되는 정보가 암호화되지 않는다는 것이었는데요. 보안에서 문제가 발생할 수 있습니다. 그것을 보안하기 위해 HTTPS로 문제를 해결할 수 있습니다.
• SSL/TLS
  • 전송계층에서 보안을 제공하는 프로토콜로 통신 간의 인터셉트를 방지합니다.
  • 인증 메커니즘, 키 교환 알고리즘, 해싱알고리즘으로 보안 세션을 만들고 보안 세션을 기반으로 데이터를 암호화한다.
    • 보안 세션 - 보안이 시작되고 끝나는 동안 유지되는 새션
• HTTPS 통신 흐름
  1. 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
  2. CA 기업을 선택하고, 공개키 관리를 맡긴다.
  3. CA: Certificate Authority로, 공개키를 저장해주는 신뢰성이 검증된 민간기업
  4. CA 기업은 기업의 이름과 CA서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에게 제공한다.
  5. A서버는 암호화된 인증서를 가지고 A서버의 공개키로 요청이 오면, 인증서를 클라이언트에게 준다.
  6. 클라이언트가 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게 된다.
  7. CA기업의 공개키는 브라우저가 알고 있고, 브라우저는 CA기업 공개키로 인증서를 해독하여 A서버의 공개키를 받는다.
  8. A서버의 공개키로 암호화해 요청을 날린다.
• SEO(Search Engine Optimization)
  • SEO는 검색엔진 최적화로 모두 같은 조건이라면 HTTPS를 지원하는 사이트가 SEO순위가 높다.
  • SEO순위를 높이려면 캐노니컬 설정, 메타 설정, 페이지 속도개선, 사이트맵 관리의 방법이 있습니다.

•