##본 포스팅은 '그림으로 배우는 Http & Network Basic - 우에노 센'을 읽고 쓴 요약/정리 글입니다.
HTTP
TCP/IP에 있는 다른 프로토콜과 마찬가지로 HTTP도 클라이언트와 서버 간에 통신을 한다.
HTTP는 클라이언트로부터 리퀘스트(Request)가 송신되며, 그 결과가 서버로부터 리스폰스(Response)로 되돌아온다.
*요청없이 응답이 오지는 않는다
> HTTP Request 메시지
Method + URI(Path) + 프로토콜 버전
+ Request 헤더
+ 엔티티(ex. name=h01010&age=100)
리퀘스트를 받은 서버는 리퀘스트 내용을 처리한 결과인 리스폰스를 클라이언트로 되돌려준다.
> HTTP Response 응답
프로토콜 버전 + 상태코드 + 상태코드 설명인 프레이즈
+ Response 헤더
+ Body(리소스 본체)
HTTP의 메소드
메소드의 종류는 다음과 같다.
메소드 이름 | 메소드 역할 | 추가 설명 |
GET | URI로 식별된 리소스 획득 | |
POST | 엔티티 전송(파라미터 전달) | 엔티티 전송에는 GET도 사용 가능하지만, 일반적으로 POST를 사용 |
PUT | 파일 전송 | 리퀘스트에 포함된 파일을 URI로 지정한 곳에 보존하도록 요구, 인증 기능이 없어서 사용X |
HEAD | 메시지 헤더 취득 | GET과 비슷, URI의 유효성과 리소스 갱신 시간을 확인 |
DELETE | 파일 삭제 | PUT과 반대, 인증 기능없어서 사용X |
OPTIONS | 제공하고 있는 메소드 문의 | 리퀘스트 URI로 지정한 리소스가 제공하고 있는 메소드를 조사, ex) response : GET, POST... |
TRACE | 경로 조사 | Max-Forwards라는 수치를 담아 요청, 서버를 통과할 때마다 감소, 0이 되는 곳에서 응답, 보안 상의 문제로 보통은 사용X |
CONNECT | 프록시에 터널링 요구 | TCP 통신을 터널링 시키기 위해서 사용, 주로 SSL과 TLS 프로토콜로 암호화된 것을 터널링 시키기 위해서 사용되고 있음, 리스폰스 후 다시 요청 가능 |
상태를 유지하지 않는 HTTP
> Stateless Protocol
HTTP는 상태를 유지하지 않는 프로토콜이다.
HTTP 프로토콜 레벨에서는 이전에 어떤 request와 response가 있었는지 전혀 기억하지 못한다.
새로운 request가 보내질 때마다 새로운 request가 생성된다.
이는 많은 데이터를 매우 빠르고 확실하게 처리하는 scalability(범위성)을 확보하기 위해서 이와 같이 간단하게 설계되어있는 것이다.
이와 같은 특성은 서버의 CPU나 메모리 같은 리소스의 소비를 억제할 수 있으며,
단순하다는 성격이기 때문에 다양한 곳에서 사용될 수 있다.
하지만 인증이 필요한 웹 페이지에서는 새로운 페이지로 이동할 떄마다 재차 로그인 정보를 보내든지, 리퀘스트마다 로그인 상태를 확인해야만 한다. 이와 같은 문제를 해결하기 위해 '쿠키'라는 시스템이 도입되었다.
> 쿠키(Cookie)
리퀘스트와 리스폰스에 쿠키 정보를 추가하여 클라이언트의 상태를 파악하기 위한 시스템이다.
- 서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 됨
- 이후에 클라이언트가 같은 서버로 리퀘스트를 보낼 때 자동으로 쿠키 값을 넣어서 송신
발전하는 HTTP
HTTP 초기 버전에서는 통신을 한번 할 때마다 TCP에 의해 연결과 종료를 반복하였다.
하지만 요구하는 리소스가 늘어날 수록 이와 같은 통신 방식은 오버헤드 발생하게 되어 통신량이 늘게되었다.
HTTP/1.1과 일부 HTTP/1.0에서는 TCP 연결 문제를 해결하기 위해 '지속 연결'이라는 방법을 고안하였다.
> 지속 연결
Persistent Connections
어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지
지속 연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인화를 가능하게 한다.
> 파이프라인화
HTTP pipelining
이전에는 리스폰스를 받을 때까지 다음 리퀘스트를 보내지 못했던 것을, 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있게 되었다.
웹 페이지를 리퀘스트한 경우, 개별 연결보다는 지속연결과 파이프라인화를 한 경우가 훨씬 빠르다.