jiseongkimu
commented
4 years ago HTTP
HyperText Transfer Protocol
-
하이퍼텍스트(HTML)문서를 교환하기 위해 만들어진 protocol(통신규약)
-
프론트-클라이언트 / 백앤드 - 프론트 서버간의 통신에도 사용된다.
-
TCP/IP기반
HTTP 통신 방식
-
요청/응답(request/response)구조
클라이언트가 HTTP request를 서버에 보내면 서버는 HTTP response를 보내는 구조. 클라이언트와 서버의 모든 통신이 요청과 응답으로 이루어 진다.
-
Stateless
즉, 요청이 오면 그에 응답을 할뿐, 여러 요청/응답 끼리 연결되어 있지 않다는 뜻이다. 즉 각각의 요청/응답은 독립적인 요청/응답 이다. 예를 들어, 클라이언트가 요청을 보내고 응답을 받은 후, 조금 있다 다시 요청을 보낼 때, 전에 보낸 요청/응답에 대해 알지 못한다는 뜻이다. 그래서 만일 여러 요청과 응답의 진행과정이나 데이터가 필요할때는 쿠키나 세션 등등을 사용하게 된다.
HTTP Request 구조
-
start line
GET /search HTTP/1.1- HTTP Method
해당 request가 의도한 action을 정의하는 부분 HTTP Methods에는 GET, POST, PUT, DELETE, OPTIONS 등등이 있다 주로 GET 과 POST과 쓰임
-
Request target 해당 request가 전송되는 목표 URI 예를 들어 /login
-
HTTP Version 말 그대로 사용되는 HTTP 버젼. 버젼에는 1.0, 1.1, 2.0 등이 있다
-
headers
Accept: */* Accept-Encoding: gzip, deflate Connection: keep-alive Content-Type: application/json Content-Length: 257 Host: google.com User-Agent: HTTPie/0.9.3- 해당 request에 대한 추가 정보(addtional information)를 담고 있는 부분 예를 들어, request 메세지 body의 총 길이 (Content-Length) 등
- Host 요청이 전송되는 target의 host url: 예를 들어, google.com
- User-Agent 요청을 보내는 클라이언트의 대한 정보: 예를 들어, 웹브라우저에 대한 정보
- Accept 해당 요청이 받을 수 있는 응답(response) 타입
- Connection 해당 요청이 끝난후에 클라이언트와 서버가 계속해서 네트워크 컨넥션을 유지 할것인지 아니면 끊을것인지에 대해 지시하는 부분
- Content-Type 해당 요청이 보내는 메세지 body의 타입. 예를 들어, JSON을 보내면 application/json
- Content-Length: 메세지 body의 길이
-
body
해당 reqeust의 실제 메세지/내용 Body가 없는 request도 많다 예를 들어, GET request들은 대부분 body가 없는 경우가 많음
HTTP Response 구조
Response도 Request와 마찬가지로 3부분으로 구성됨
-
Status line
HTTP/1.1 404 Not Found- HTTP 버젼
- Status code: 응답 상태를 나타내는 코드. 숫자로 되어 있는 코드(ex : 200)
- Status text: 응답 상태를 간략하게 설명해주는 부분(ex : Not Found)
-
Headers
- Response의 headers와 동일하다. 다만 response에서만 사용되는 header 값들이 있다. 예를 들어, User-Agent 대신에 Server 헤더가 사용된다
-
Body
- Response의 body와 일반적으로 동일하다.
- Request와 마찬가지로 모든 response가 body가 있지는 않다. 데이터를 전송할 필요가 없을경우 body가 비어있게 된다
HTTP 메소드
GET
서버에게 Resource를 보내도록 요청하는데 사용(서버의 Resource를 읽음)
HEAD
GET과 동일하지만 서버에서 Body를 리턴하지 않음
- Resource를 받지 않고 오직 찾기만 원할 때
- object가 존재할 경우 응답의 상태 코드를 확인할 때
- 서버의 응답 헤더를 봄으로써 Resource가 수정 되었는지 확인
PUT
서버에 문서를 쓸 때 사용(GET과 반대)
- PUT메소드는 서버가 Client요청의 Body를 확인한다
- 요청된 URL에 정의된 새로운 Resource를 생성하기 위해서 사용
- 요청된 URL이 존재 할 경우 대체하여 사용
PATCH
PUT과 유사하게 요청된 자원을 수정함
PUT은 자원 전체를 갱신하지만, PATCH는 해당자원의 일부를 교체함
POST
Server에 Input Data를 보내기 위해 사용(HTML form에 많이 사용)
- PUT vs POST
- PUT은 서버의 Resource에 Data를 저장하기 위한 용도
- POST는 서버에 Data를 보내기 위한 용도
TRACE
Client로 부터 Request Packet이 방화벽, Proxy Server, Gateway등 을 거치면서 패킷의 변조가 일어날 수 있는데, 이 때 Server에 도달했을 때의 최종 패킷의 Request Packet을 볼 수 있다.
- Original Data와 서버에 도달했을 때의 비교 본 Data를 서버의 응답 Body를 통해 확인할 수 있다
- 요청의 최종 수신자는 반드시 송신자에게 200(OK)응답의 내용(Body)로 수신한 메시지를 반송 해야함
- 최초 Client의 요청에는 Body가 포함될 수 없다
OPTION
Target Server의 지원 가능한 메소드를 알아보기 위해 사용
DELETE
요청 Resource를 삭제하도록 요청
- 그러나 HTTP 규격에는 Client의 요청에도 서버가 무효화 시킬 수 있도록 정의되어 있다
- 항상 보장되지 않는다
HTTP 응답 코드
| 응답 대역 | 응답 코드 | 내용 |
|---|---|---|
| 정보전송 / 임시응답 | 1XX | 요청을 받았으며 프로세스를 계속 진행함 |
| 성공 | 2XX | 요청을 성공적으로 수신, 처리했음 |
| 리다이렉션 | 3XX | 요청 완료를 위한 추가 작업 조치가 필요함 |
| 클라이언트 요청 에러 | 4XX | 요청의 문법이 잘못되었거나 요청을 처리할 수 없음 |
| 서버 에러 | 5XX | 서버가 요청을 수행하지 못했음 |
DaeAkin
GET POST PUT DELETE PATCH
헤더 리퀘스트바디 등등.