HTTP

• HTTP는 어플리케이션 계층의 대표 스택, 웹서비스 통신에 사용 됨
• TCP/IP 4계층 구조: 어플리케이션 - 전송 - 인터넷 - 링크

 

HTTP/1.0

• 한 연결당 하나의 요청을 처리하도록 설계 됨
• RTT(패킷이 목적지에 도달하고 다시 출발지로 돌아오는 데 걸리는 시간)가 증가함
  • 왜? 서버에서 파일 가져올 때마다 TCP 3 way handshake 해야 됨
• 매번 연결할 때마다 RTT가 증가하니까 서버에 부담이 가서, 이를 해결하기 위한 방법이 제시 됨
  • 이미지 스플리팅
    • 많은 이미지가 합쳐 있는 하나의 이미지를 다운받고, 이를 기반으로 background-image의 position을 이용해 이미지를 표기
  • 코드 압축: 개행 문자, 빈칸 없애서 코드 크기 최소화
  • 이미지 Base 64 인코딩: 이미지 파일을 64진법 문자열로 인코딩. 그러나 37% 정도 크기가 커지는 문제가 있음

HTTP/1.1

• 매번 TCP 연결을 하지 않고, 한 번 TCP 초기화를 한 이후 keep-alive 옵션으로 여러 개 파일 송수신할 수 있음
• HTTP/1.0에도 keep-alive가 있었지만 표준화가 되어 있지 않았고, 1.1부터 기본 옵션으로 설정됨
• 문서 안에 포함된 리소스가 여러 개라면 비례해서 대기 시간이 길어짐
  • Head of Line Blocking: 같은 큐에 있는 패킷이 첫 번째 패킷에 의해 지연되는 경우(특정 파일 용량이 엄청 큼)
  • 1.1에는 헤더에 쿠키 등 메타 데이터가 많이 들어 있고 압축이 안되어 무거움

 

HTTP/2.0

• 1.X보다 지연 시간을 줄이고 응답 시간을 더 빠르게 할 수 있음
• 멀티 플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위 처리를 지원함
• 멀티플렉싱
  • 여러 개의 스트림을 사용해 송수신함. 특정 스트림의 패킷이 손실되어도 나머지는 영향이 없음.
  • 병렬적인 스트림을 통해 데이터를 서빙하고, 스트림 내의 데이터도 조각남. 송수신 후 다시 재조립함.
• 헤더 압축
  • 1.X의 큰 헤더 문제를 해결하기 위한 압축
  • 허프만 코딩 압축 알고리즘 - HPACK 압축 형식
    • 허프만 코딩: 문자열을 문자 단위로 쪼개 비트 수를 세어 정보 빈도에 "반비례"하는 비트 수를 사용함
• 서버 푸시
  • 1.X에서는 클라이언트가 서버에 요청을 해야 파일을 다운받을 수 있었음
  • 2부터는 클라이언트 요청 없이 서버가 바로 파일을 푸시할 수 있음. HTML만 요청해도 CSS를 같이 푸시하는 등

HTTPS

• HTTP/2는 HTTPS 위에서 동작
• HTTPS는 어플리케이션 계층과 전송 계층 사이에 신뢰계층인 SSL/TLS를 넣음. 신뢰할 수 있는 HTTP 요청
• 제3자가 메시지를 도청하거나 변조하지 못하도록 함.
• SSL/TLS를 통해 공격자가 서버인 척하며 사용자 정보를 가로채는 네트워크상의 인터셉터를 방지함
• 보안 세션
  • SSL/TLS는 핸드셰이크로 보안 세션을 생성하고, 이를 기반으로 상태 정보를 공유함
  • 클라이언트와 서버가 키를 공유하고, 인증확인이 일어난 후 데이터를 송수신함
    • 클라이언트에서 cyper suites를 서버에 전달함
    • 서버는 받은 사이퍼 수트의 암호화 알고리즘 리스트를 제공할 수 있는지 확인함
    • 제공할 수 있으면 서버에서 클라이언트로 인증서를 보내는 인증 메커니즘이 시작됨
    • 해싱 알고리즘 등으로 암호화된 데이터의 송수신이 시작됨
  • 사이퍼 수트 - 프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘이 나열된 규약
    • ex) TLS_AES_128_GCM_SHA256
    • 프로토콜: TLS, AES_128_GCM: AEAD 사이퍼 모드, SHA256: 해싱 알고리즘
  • AEAD 사이퍼 모드 - 데이터 암호화 알고리즘
    
    • AES_128_GCM: 128비트의 키를 사용하는 표준 블록 암호화 기술+병렬 계산에 용이한 암호화 알고리즘 GCM
  • 인증 매커니즘: CA, certificate authorities에서 발급한 인증서를 기반으로 이루어짐
    • CA에서 발급한 인증서는 안전한 연결을 시작하는 데 있어 필요한 공개키를 클라이언트에 제공
    • 사용자가 접속한 서버가 신뢰할 수 있는 서버임을 보장함
    • 인증서: 서비스 정보, 공개키, 지문, 디지털 서명 등으로 이루어짐
    • CA는 신뢰성이 엄격하게 공인된 기업만 참여할 수 있음
    • CA 발급 과정
      • 자신의 사이트 정보과 공개키를 CA에 제출
      • 공개키를 해시한 값(finger print)을 사용하는 CA 기반으로 CA 인증서 발급
  •  암호화 알고리즘: 키 교환 암호화 알고리즘은 대수곡선 기반 또는 모듈식 기반을 사용. 둘다 디피-헬만 베이스
    
    • 디피-헬만 키 교환 암호화 알고리즘: 암호키를 교환하는 방법
      • y = g^(x)mod p
      • g, x, p를 알면 y를 구하기 쉽지만, g,y,p를 알면 x를 구하기 어려운 원리 사용
      • 처음에 공개 값을 공유하고, 각자 비밀 값과 혼합한 후 혼합 값을 공유.
      • 각자의 비밀 값과 혼합값을 혼합해 공통 암호키 psk 생성
      • 공격자는 psk가 없어서 개인키나 공개키가 있어도 아무것도 못함
  • 해싱 알고리즘: 데이터를 추정하기 힘든 작고 섞인 조각으로 만드는 것
    • SHA-256
      • 해시 함수의 결과값이 256 비트인 알고리즘
      • 해싱해야 할 메시지에 1을 추가하는 등 전처리를 하고, 전처리된 메시지를 기반으로 해시 반환
• TLS 1.3은 사용자가 사이트 재방문하면 SSL/TLS에서 보안 세션 만들 때 걸리는 통신 안해도 됨 (0-RTT)

 

SEO 관리

• SEO 검색 엔진 최적화
• 캐노니컬 설정: 사이트 link에
• 메타 설정
• 페이지 속도 개선
• 사이트맵 관리

 

HTTPS 구축 방법

• 직접 CA에서 구매한 인증키 기반으로 HTTPS 서비스 구축
• 서버 앞단에 HTTPS 제공하는 로드밸런서 둠
• 서버 앞단에 HTTPS 제공하는 CDN 둠

 

HTTPS/3

• TCP 위에서 돌아가는 HTTP/2와 다르게 QUIC 계층에서 돌아가며, UDP 기반임
• 멀티플렉싱을 가지고 있음
• 초기 연결 시 시간 감소 - UDP 기반이라서
  • 3웨이핸드쉐이크 안해도 됨
  • QUIC는 첫 연결에 1-RTT만 소요
  • 클라이언트가 서버에 신호를 보내고, 응답만 하면 바로 통신 시작 가능
  • QUIC은 순방향 오류 수정 메커니즘을 적용해서 전송한 패킷이 손실되었다면 수신 측에서 에러를 검출하고 수정하는 방식을 사용함. 열악한 네트워크 환경에서도 낮은 패킷 손실률을 자랑함.