CS - HTTP

🌱 오늘의 주제  : HTTP

 

 

 

 

 

 

 

 

 

🌱 HTTP

---

• 기본적으로 HTTP는 애플리케이션 계층으로서 웹 서비스 통신에 사용된다. 
• HTTP/1.0  -> HTTP/1.1 -> HTTP/2 -> HTTP/3

 

 

 

 

🌱 HTTP/1.0

---

• HTTP/1.0은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되어있다. 이는 RTT 증가를 불러오게 되었다.
  • RTT란, 패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간이며 패킷 왕복 시간이다.
• RTT의 증가를 해결하기 위한 방법 : 이미지 스플리팅, 코드 압축, 이미지 Base64 인코딩을 사용.

 

 

 

 

 

 

🌱 HTTP/1.1

---

• 매번 TCP 연결을 하는 것이 아니라, 한번 TCP 초기화를 한 이후에 keep-alive라는 옵션으로 여리 개의 파일을 송수신 할 수 있게 바뀌었다.
• HTTP/1.1 부터 keep-alive가 표준화가 되어 기본 옵션으로 설정되었다.
• 한 번  TCP 3-웨이 핸드셰이크가 발생하면 그 다음부터 발생하지 않는다. 
• 문서 안에 포함된 다수의 리소스(이미지, 동영상, css, js 파일) 를 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어지는 단점이 있다.
• HOL Blocking(Head Of Line Blocking) 발생하는 단점이 있다. 
  • HOL Blocking(Head Of Line Blocking)은 네트워크에서 같은 큐의 첫번 째 패킷이 지연될 때 발생하는 성능 저하 현상을 말한다.
• 헤더에 쿠키 등 많은 메다데이터가 들어 있고 압축이 되지 않아 무겁다.

 

 

 

 

 

 

 

🌱 HTTP/2

---

• HTTP/2는 SPDY 프로토콜에서 파생된 HTTP/1.x 보다 지연 시간을 줄이고 응답 시간을 더 빠르게 처리할 수 있으며 멀티플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위 처리를 지원하는 프로토콜이다.
• 멀티플렉싱이란 여러 개의 스트림을 사용하여 송수신하는 것. -> HOL Blocking 해결. 
  • 스트림이란 ? 시간이 지남에 따라 사용할 수 있게 되는 일련이 데이터 요소를 가리키는 데이트 흐름 
• 헤더 압축은 허프만 코딩 (huffman coding) 압축 알고리즘을 사용하여 전체 데이터의 표현에 필요한 비트양을 줄이는 원리이다. 
  • 허프만 코딩이란 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 사용하여 표현하고, 빈도가 낮은 정보는 비트 수를 많이 사용하여 표현해서 전체 데이터의 표현에 필요한 비트양을 줄이는 원리이다.
• 서버 푸시는 클라이언트 요청 없이 서버가 바로 리소스를 푸시 할 수 있는 것이다. 

 

 

 

# 참고 

SPDY란 - https://d2.naver.com/helloworld/140351

 

 

 

 

 

 

🌱  HTTPS

---

• HTTP/2는 HTTPS위에서 동작한다. 
• HTTPS는 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 SSL/TLS 계층을 넣은 신뢰 할 수 있는 HTTP 요청을 말한다. 이를 통해 '통신을 암호화'한다.
  
  • SSL/TLS은 전송 계층에서 보안을 제공하는 프로토콜이다.  클라이언트와 서버가 통신 할 때 SSL/TLS를 통해 제3자가 메시지를 도청하거나 변조하지 못하도록 하는 것이다.  
  • SSL/TLS는 보안 세션을 기반으로 데이터를 암호화하여 보안 세션이 만들어질 때 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘이 사용된다.
• 보안 세션이란 보안이 시작되고 끝나는 동안 유지되는 세션을 말하고, SSL/TLS는 핸드셰이크를 통해 보안 세션을 생성하고 이를 기반으로 상태 정보 등을 공유한다. 
• 인증 메커니즘 CA(Certificate Authorities)에서 발급한 인증서를 기반으로 이루어진다. CA에서 발급한 인증서는 안전한 연결을 시작하는데 있어 필요한 '공개키'를 클라이언트에 제공하고 사용자가 접속한 '서버가 신뢰'할 수 있는 서버임을 보장한다. 
• 암호화 알고리즘은 디피-헬만(Diffie-Hellman)방식으로 만들어졌다. 
  • 디피-헬만 키 교환 암호화 알고리즘은 암호키를 교환하는 하나의 방법이다.  

 

 

 

 

• 해싱 알고리즘은 데이터를 추정하기 힘든 더 작고, 섞여 있는 조각으로 만드는 알고리즘이다. 
  • SHA-256알고리즘과 SHA-384 알고리즘이 있다.
• SEO(Search Engine Optimization)에도 도움되는 HTTPS
  • 구글은 SSL 인증서를 강조해왔고 HTTPS 서비스를 하는 사이트가 SEO 순위가 높을 것이라고 공식적으로 밝혔다.
• HTTPS 구축 방법 
  • 1. 직접 CA에서 구매한 인증키를 기반으로 HTTPS 서비스를 구축한다.
  • 2. 서버 앞단의 HTTPS를 제공하는 로드밸런서를 둔다.
  • 3. 서버 앞단에 HTTPS를 제공하는 CDN을 둬서 구축한다. 

 

 

 

# 참고

CDN이란 - https://aws.amazon.com/ko/what-is/cdn/

로드밸런서란 - https://m.post.naver.com/viewer/postView.naver?volumeNo=27046347&memberNo=2521903 

로드밸런서(Load Balancer)의 개념과 특징

CDN이란 무엇인가요? - 콘텐츠 전송 네트워크 설명 - AWS

 

 

 

 

 

🌱 HTTP/3

---

• TCP 위에서 돌아가는 HTTP/2와는 달리 HTTP/3은 QUIC이라는 계층 위에서 돌아간다. 
• TCP 기반이 아닌, UDP 기반으로 돌아간다.

 

 

 

• QUIC은 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3-웨이 핸드셰이크 과정을 거치지 않아도 되기에 초기 연결 설정 시 지연 시간이 감소된다.
• QUIC은 첫 연결 설정에 1-RTT만 소요된다. 클라이언트가 서버에 어떤 신호를 한 번주고, 서버도 거기에 응답하기만 하면 바로 본 통신을 시작할 수 있다. 
  • QUIC은 순방향 오류 수정 메커니즘(FEC, Forword Error Correction)이 적용되었다.  전송한 패킷이 소실되었다면 수신 측에서 에러를 검출하고 수정하는 방식이며 열악한 네트워크 환경에서도 낮은 패킷 손실률을 자랑한다.

 

 

 

 

 

 

 

 

🌱 HTTP 의 문제점

---

• HTTP 는 평문 통신이기 때문에 도청이 가능하다.
• 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
• 완전성을 증명할 수 없기 때문에 변조가 가능하다.

위 세 가지는 다른 암호화하지 않은 프로토콜에도 공통되는 문제점들이다.

 

 

 

TCP/IP 는 도청 가능한 네트워크이다.

 

TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것만으로 도청할 수 있다. 평문으로 통신을 할 경우 메시지의 의미를 파악할 수 있기 때문에 암호화하여 통신해야 한다.

보완 방법

1. 통신 자체를 암호화 SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 다른 프로토콜을 조합함으로써 HTTP 의 통신 내용을 암호화할 수 있다. SSL 을 조합한 HTTP 를 HTTPS(HTTP Secure) or HTTP over SSL이라고 부른다.
2. 콘텐츠를 암호화 말 그대로 HTTP 를 사용해서 운반하는 내용인, HTTP 메시지에 포함되는 콘텐츠만 암호화하는 것이다. 암호화해서 전송하면 받은 측에서는 그 암호를 해독하여 출력하는 처리가 필요하다.

 

 

 

통신 상대를 확인하지 않기 때문에 위장이 가능하다.

HTTP 에 의한 통신에는 상대가 누구인지 확인하는 처리는 없기 때문에 누구든지 리퀘스트를 보낼 수 있다. IP 주소나 포트 등에서 그 웹 서버에 액세스 제한이 없는 경우 리퀘스트가 오면 상대가 누구든지 무언가의 리스폰스를 반환한다. 이러한 특징은 여러 문제점을 유발한다.

1. 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지를 확인할 수 없다.
2. 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지를 확인할 수 없다.
3. 통신하고 있는 상대가 접근이 허가된 상대인지를 확인할 수 없다.
4. 어디에서 누가 리퀘스트 했는지 확인할 수 없다.
5. 의미없는 리퀘스트도 수신한다. —> DoS 공격을 방지할 수 없다.

보완 방법

위 암호화 방법으로 언급된 SSL로 상대를 확인할 수 있다. SSL 은 상대를 확인하는 수단으로 증명서 를 제공하고 있다. 증명서는 신뢰할 수 있는 제 3 자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성이 줄어들게 된다. 한 가지 이점을 더 꼽자면 클라이언트는 이 증명서로 본인 확인을 하고 웹 사이트 인증에서도 이용할 수 있다.