HTTP
HTTP란?
HyperText Transfer Protocol. 웹의 구성요소들이 데이터를 주고받기 위해 정의한 통신 프로토콜
특징
- 상태가 없다(stateless). 즉, 서버가 클라이언트의 이전 상태를 보존하지 않는다.
-> 이전 상태 정보가 필요한 경우를 위해 쿠키등을 사용할 수 있음. - 80번 포트를 사용한다.
HTTP/1.0
- 각 요청/응답에 대해서 매번 TCP Connection이 필요하다.
HTTP/1.1
- persistent connecting 도입. (일정 시간동안 connection을 닫지 않는 방식)
- 커넥션당 하나의 요청과 응답만 처리한다. 즉, 여러개의 요청과 응답을 한번에 전송할 수 없다.
- TCP/IP 통신위에서 동작한다.
- 리소스의 개수에 비례하여 응답시간이 증가한다.
HTTP/2
- HTTP 메시지를 사람이 읽을 수 없게 캡슐화 한다.
- 중복헤더 제거
- 커넥션당 여러개의 요청과 응답이 처리 가능하다. 즉, 다중요청 및 응답이 가능하다.
- TCP/IP 통신위에서 동작한다.
- HTTP/1.1보다 약 50%가량 빠르다
HTTP/3
- UDP를 경유하여 사용되는 QUIC(Quick UDP Internet Connections) 프로토콜을 사용한다.
- HOL(Head-Of-Line-Blocking) 이라는 TCP의 HTTP/2의 주된 문제를 해결하려는 목적
HOL : 입력포트에서 패킷이 출력 포트로 전달되지 못하고 대기상태에 있는 현상
HTTPS
HTTP에 데이터 암호화가 추가된 프로토콜 (Secure의 S)
- 네트워크 상에서 중간에 제3자가 데이터를 볼 수 없도록 공개키/개인키 암호화를 지원한다.
- 대칭키
- 암호화에 사용하는 키 = 복호화에 사용하는 키
- 송신자 - 수신자가 동일한 대칭키를 가지고 있어야 한다.
- 키 배송 중에 키가 탈취될 수 있다.
- 통신하는 사람이 증가할 수록 따로따로 키 교환을 해야하기때문에 관리해야 할 키가 방대하게 많아진다.
- 공개 암호화 방식에 비해 속도가 빠르다
- 비대칭키(공개키)
- 암호화에 사용하는키 ≠ 복호화에 사용하는 키
- 공개키 - 개인키 쌍(암호화키 - 복호화키 쌍)
- 공개는 키가 공개되어있기 때문에 따로 키교환이나 분배를 할 필요가 없어진다.
- 개인키를 가지고 있는 수신자만이 암호화된 데이터를 복호화할 수 있다.
- 대칭키 방식에 비해 속도가 느리다.
- 대칭키
- 443번 포트를 사용한다.
- 인증기관에서 검증된 사이트만 https주소를 사용할 수 있기 때문에 신뢰할 수 있는 사이트라는것을 증명한다.
- HTTPS 인증받는법
- 개인 키와 공개 키 쌍을 만들고 조직과 공개 키에 관한 정보를 포함하는 CSR(Certificate Signing Request)을 준비한다.
- 인증 기관에 연결해 CSR 기반 HTTPS 인증서를 요청한다.
- 서명된 HTTPS 인증서를 획득하고 웹 서버에 인증서를 설치한다.
- HTTPS 예
- HTTP 예
국방부는 https를 사용하지만 국토교통부는 http로 되어있다. 세금이 가성비있게 사용되고있는 모습이다.
- HTTPS 인증받는법
HTTP 메시지 구조
start-line 시작 라인
header 헤더
message body
empty line 공백 라인(CRLF, 필수)
-
시작라인
요청 (request-line)
HTTP메서드 요청대상 HTTP버전
예)GET /search?q=hello&hl=ko HTTP/1.1- HTTP메서드 : GET, POST, PUT, DELETE, ...
- 요청 대상 : /로 시작하는 절대경로로 작성 (절대경로[?쿼리])
응답 (status-line)
HTTP버전 상태코드 상태문구
예)HTTP/1.1 200 OK- 상태코드 : 요청의 성공, 실패를 나타내는 코드
200 : 성공, 400 : 클라이언트 요청 오류, 500 : 서버 내부 오류
- 상태문구 : 사람이 이해할 수 있는 짧은 상태 설명 글
-
헤더라인
요청
예)Host: www.google.com
응답
예)Content-type: text/html;charset=UTF-8
HTTP전송에 필요한 부가정보가 들어있음.
(메시지 바디의 내용, 크기, 압축, 인증, 요청 클라이언트 정보, 서버 애플리케이션 정보, 캐시관리 정보 등...)
key : value 로 되어있다 -
메시지 바디
실제 전송할 데이터가 담겨있는 부분
HTTP Methods
- GET : 데이터 받아오기
- POST : 데이터 생성/수정/삭제. (멱등x)
- OPTIONS : 요청 URI에서 사용할 수 있는 Method를 받아올 때 사용
- PUT : 데이터 생성/수정. 리소스의 모든 속성을 수정하기 위해 사용. POST랑 겹쳐서 잘 안씀. (멱등o)
- PATCH : 데이터의 수정. 리소스의 일부분만 수정하기 위해 사용.
- DELETE : 데이터 삭제. POST랑 겹쳐서 잘 안씀
HTTP 커넥션
HTTP 커넥션은 몇가지 규칙을 제외하고는 TCP 커넥션과 동일합니다.
TCP는 HTTP에게 신뢰할 수 있는 통신 방식을 제공합니다.
HTTP 트랜잭션의 지연
HTTP 트랜잭션은 다음과 같은 과정을 거칩니다.
DNS 찾기 - TCP 연결 - TCP 요청 전송 - 서버단에서의 처리 - TCP 응답 전송
위에서 보이는 바와 같이 HTTP 요청 과정에서는 TCP 커넥션을 설정하고, 요청을 전송하고, 응답 메시지를 보내는 것에서 많은 시간이 소요됩니다.
따라서 TCP 성능의 특성을 이해하면 HTTP 커넥션 최적화를 잘 해낼 수 있습니다.
TCP 성능에 대한 고려
TCP 네트워크 지연은 하드웨어의 성능, 네트워크와 서버의 전송 속도, 메시지의 크기, 클라이언트와 서버간의 거리, TCP 프로토콜의 기술적인 복잡성에 크게 영향을 받습니다.
특히, HTTP 프로그래머에게 영향을 주는 가장 일반적인 TCP지연요소는 다음과 같습니다.
-
TCP 커넥션의 핸드셰이크 설정
HTTP 트랜잭션의 상당부분은 커넥션의 생성단계인 핸드셰이크에 의해 지연됩니다.
이러한 지연을 제거하기 위해 HTTP는 이미 존재하는 커넥션을 재활용 합니다. -
인터넷의 혼잡을 제어하기 위한 TCP의 느린 시작
TCP 커넥션은 몇번의 데이터를 주고 받으면서 튜닝을 거쳐 최대 속도 제한을 높여나갑니다.
이 때문에 새롭게 생성된 튜닝되지않은 커넥션은 느립니다. -
데이터를 한데 모아 한 번에 전송하기 위한 네이글 알고리즘
네이글 알고리즘은 네트워크의 효율을 위해, 세그먼트가 최대크기가 되지 않으면 전송을 하지 않다가 전송하기 충분한 만큼의 패킷이 쌓였을 때 함께 전송합니다.
HTTP 애플리케이션의 성능향상을 위해 HTTP 스택에 TCP_NODELAY 파라미터 설정을 통해 이를 비활성하기도 합니다. -
TCP의 편승(piggyback) 확인응답(acknowlegment)을 위한 확인응답 지연 알고리즘
TCP 커넥션에서는 신뢰성있는 통신을 위해 요청에 대한 확인응답 패킷을 반환하는데, 이 확인응답 패킷은 크기가 작기때문에 주변 송출 데이터 패킷에 같이 실려갈 수 있습니다.
이 때 이 확인 응답이 버퍼에 특정시간동안 머물러 있으면서 송출 데이터 패킷을 찾는 알고리즘에 의해 시간이 지연됩니다.
이 기능은 수정하거나 비활성화 할 수 있습니다. -
TIME_WAIT 지연과 포트 고갈
제한되어있는 수의 포트가 고갈되는 현상에 의해 커넥션이 지연되기도 합니다.
HTTP 커넥션에 대한 고려
- Connection 헤더에 대한 잘못된 이해
- 순차적인 트랜잭션 처리에 의한 지연
리소스를 순차적으로 로드 하는 방식은 물리적/심리적 지연을 야기합니다.
HTTP 커넥션의 성능을 향상시키는 기술
병렬 커넥션
여러개의 커넥션을 연결하여 HTTP 트랜잭션을 순차적으로 처리하는것이 아닌, 병렬적으로 동시에 처리하는 방법입니다.
- 페이지를 더 빠르게 내려받습니다.
일반적으로 객체가 여러개 있는 웹페이지를 더 빠르게 내려받을 수 있습니다. HTML 페이지를 먼저 내려받고 남은 트랜잭션이 병렬로 로드되어 총 지연시간이 줄어듭니다. - 항상 더 빠르지는 않습니다.
네트워크 대역폭이 좁은경우(즉, 데이터 전송 속도가 느린경우) 병렬 커넥션을 생성하는 부하때문에 오히려 더 오래걸릴수도 있습니다.
다수의 커넥션은 메모리를 많이 소모하고 자체적인 성능 문제를 발생시킵니다. - 실제로는 순차적인 처리보다 느리더라도 사용자는 심리적으로 더 빠르다고 느낄 수 있습니다.
- 각 트랜잭션마다 새로운 커넥션을 맺고 끊기 때문에 시간과 대역폭이 소요됩니다.
- 각각의 새로운 커넥션은 TCP의 느린 시작 때문에 성능이 떨어집니다.
- 실제로 연결할 수 있는 병렬 커넥션의 수에는 제한이 있습니다.
지속 커넥션
처리가 완료된 후에도 계속 연결상태로 있는 TCP 커넥션을 말합니다.
HTTP/1.1버전을 지원하는 기기는 TCP 커넥션을 유지하여 이후의 HTTP 요청에 재사용 할 수 있습니다.
- 커넥션을 맺기위한 준비작업에 따르는 시간을 절약할 수 있습니다.
- TCP의 느린 시작을 피하고 튜닝된 커넥션을 유지합니다.
- 커넥션의 수를 줄여줍니다.
- 지속 커넥션을 잘못 관리할 경우, 계속 연결된 상태로 있는 수많은 커넥션이 쌓여 리소스의 불필요한 소모를 발생시킵니다.
Keep-Alive 커넥션
- HTTP/1.0 에서 지원하는 지속 커넥션입니다. 설계상의 문제가 있었기 때문에 HTTP/1.1 명세에서는 빠졌습니다.
- 커넥션을 유지하기 위해서 요청 혹은 응답에
Connection:Keep-Alive헤더를 포함시킵니다. 이 헤더가 없으면 메시지가 전송 된 후 서버 커넥션을 끊을 것이라 추정합니다. - keep-alive 동작은
Keep-Alive헤더의 쉼표로 구분된 옵션 값들로 제어할 수 있습니다.
