2.1 HTTP는 클라이언트와 서버 간에 통신을 한다
HTTP프로토콜엣는 반드시 한곳은 클라이언트 한곳은 서버의 역할을 합니다.
2.2 리퀘스트와 리스폰스를 교환하여 성립
HTTP는 클라이언트로부터 요청이 송신되며 결과가 리스폰스로 돌아옵니다
// (메소드) (URI) (프로토콜 버전)
Post /form/entry HTTP/1.1
// 리퀘스트 헤더 필드
Host: example.kr
Connection: keep-alive
// 엔티티
name-~~
JavaScript
복사
2.3 HTTP는 상태를 유지하지 않는 프로토콜
HTTP는 스테이스리스 프로토콜로 상태를 유지하지 않고, 매번 새로운 통신을 연결합니다. 따라서 기존 사용자 파악을 위해 쿠키 등의 기술이 도입되었습니다.
2.4 리퀘스트 URI로 리소스를 식별
HTTP는 URI를 사용하여 인터넷 상의 리소스를 지정하는데 어느 곳에 있어도 지정할 수 있습니다.
URI지정의 경우 (1)리퀘스트 URI에 넣는 방법과 (2)헤더 필드에 넣는 방법 2가지가 있습니다.
// 1번
GET example.kr HTTP/1.1
// 2번
GET /index.html HTTP/1.1
Host: example.kr
JavaScript
복사
2.5 서버에 임무를 부여하는 HTTP 메소드
•
GET : URI로 식별 된 리소스 획득
•
POST : 엔티티 전송 및 리소스 획득
•
PUT : 파일 전송을 위해 사용하지만 PUT과 DELETE의 경우 서버의 상태를 바꾸기 때문에 위험합니다. 따라서 이용을 위해서는 인증 기능과 같이 사용하거나 REST와 같은 설계 방식을 사용해야 합니다.
REST와 같이 사용할 때 안전한 이유 : 공격자가 수정할 리소스의 정확한 URI를 알아야 하므로 난이도가 높아지며, 추가 보안 수단이 요구되는 경우가 많기 때문입니다.
•
HEAD : 메시지 헤더 획득
•
DELETE : 파일 삭제 - PUT과 동일
•
OPTIONS : 제공하고 잇는 메소드의 문의
•
TRACE : 자신에게 통신을 되돌려 받는 루프백을 통해 오리진 서버에 접속할 때 동작 확인을 위해 사용됩니다. 하지만 보안 상의 문제가 있어 거의 사용되지 않습니다.
•
CONNECT : 양방향 연결을 시작하는 메소드로, 터널을 열기 위해 사용되는데 SSL을 사용하는 웹사이트 등에 사용됩니다.
REST(Representatailnal State Transfer) : URI를 통해 자원을 표시하고, HTTP Method를 이용하여 결과를 받는 것
2.6 메소드를 사용해서 지시내리기
리퀘스트를 날리는데 메소드를 통해 어떠한 행동을 할 지 알리는데, 대소문자를 구분하기 때문에 대문자로 적어야합니다.
2.7 지속 연결로 접속량을 절약
초기에는 단순 텍스트만을 주고 받았기에 문제가 없었지만, 이미지 등 통신량이 늘어나 매번 접속을 하는 번거로움이 생겼습니다.
2.7.1 지속 연결
HTTP/1.1부터 TCP는 1회의 연걸을 통해 리퀘스트와 리스폰스을 여러 번 주고 받을 수 있게 되었습니다.
2.7.2 파이프라인화
파이프라인을 통해서 리퀘스트를 보낸 후 리스폰스를 기다리지 않고 바로 다음 리퀘스트를 날릴 수 있게 되었습니다.
TCP는 흐름 제어와 혼잡 제어를 위해 여러가지 정책을 사용해서 신뢰성을 확보하고 있습니다. 참조
2.8 쿠키를 사용한 상태 관리
HTTP는 스테이트리스 프로토콜이기 때문에 과거 상태를 알기 위해서 쿠키라는 시스템을 사용합니다. 서버에서 리스폰스를 보낼 때 Set-Cookie를 통해 클라이언트에 보존해 해당 값으로 상태를 확인합니다.