티스토리 뷰
반응형
HTTP에서 서버와 클라이언트
서버: 리소스를 제공 (Request)
클라이언트: 리소르를 요청 (Response)
💡 HTTP 프로토콜에서 클라이언트와 서버의 역할은 정해져 있고, HTTP는 이 클라이언트와 서버의 역할을 구분한다.
💡 클라이언트의 Request부터 통신이 시작된다. 서버는 Ruquest가 없다면 응답을 하지 않는다.
Request 메시지의 형태
GET /sdardew.html HTTP /1.1
Host: www.tistory.com
sdardew.html을 요청하는 메시지
GET
- 메서드
- 서버가 수행해야 하는 행동
/sdardew.html
- 리퀘스트 URI
- 요청하는 대상
HTTP/1.1
- 프로토콜 버전
- 클라이언트 기능을 식별
POST /sdardew.html HTTP /1.1
Host: www.tistory.com
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 5
abcde
POST
- 메서드
/index.html
- URI
HTTP /1.1
- 프로토콜 버전
Host ~Content-Length (4줄)
- 리퀘스트 헤더
- 리소스나 클라이언트에 대한 정보를 포함하는 헤더
abcde
- 엔티티 헤더
- 메시지 바디의 컨텐츠
- Cotent-Length에 있는 길이(5)의 크기를 가짐
Response 메시지의 형태
HTTP /1.1 200 OK
Date: Sat, 30 Dec 2021 10:20:30 GMT
Content-Length: 365
Content-Type: text/html
<html>
...
HTTP /1.1
- 서버의 프로토콜 버전
200 OK
- 리퀘스트 처리 결과
Date ~ Content-Type
- 헤더
- 헤더의 끝은 \n\n로 구분
<html>~
- 바디
- 리소스
Stateless
HTTP는 상태가 계속 유지되지 않는 프로토콜이다.
이런 stateless는 서버의 리소스를 절약할 수 있다는 장점이 있다.
하지만, 로그인과 같은 경우에는 상태를 유지하는 것이 필요하다.
이때 Cookie를 사용하여 HTTP의 상태를 유지할 수 있다.
쿠키
- Stateless 프로토콜의 문제를 해결
- REQUEST, RESPONSE에 정보를 추가하여 상태를 파악할 수 있게 해줌
클라이언트가 쿠키를 획득하는 과정
- 쿠키를 가지지 않은 상태에서 리퀘스트
- 서버는 Set-Cookie에 쿠키를 담아 클라이언트에게 전송
- 클라이언트는 쿠키를 가짐
클라이언트는 쿠키를 받았던 서버에 request를 보낼 때마다 자동으로 쿠키 값을 담아 같이 전송한다.
서버는 쿠키로 인해 클라이언트의 상태를 알 수 있다.
URI (Uniform Resource Identifiers)
HTTP는 URI를 통해 리소스를 지정한다.
리소스를 지정하는 방법
- 모든 URI를 리퀘스트 URI에 포함
GET http://tistory.com/sdardew.html HTTP/1.1
- Host 헤더 필드에 네트워크 로케이션 포함
GET /sdardew.html HTTP/1.1
Host: tistory.com
💡 URI가 *이면 서버 자신에게도 리퀘스트를 송신
OPTIONS * HTTP/1.1 HTTP : 서버가 지원하고 있는 메서드
HTTP/1.1 메서드 종류
GET
- URI의 리소스 요청
GET /sdardew.html HTTP/1.1
Host: tistory.com
GET /sdardew.html HTTP/1.1
Host: tistory.com
If-Modified-Since: Sat. 30 Dec 2021 10:0:0 GMT
sdardew.html 리소스가 2021년 10월 30일 10시 이후로 변경이 있는 경우 리소스를 전송하고 아닌 경우 304 Not Modified 메시지를 전송한다.
POST
- 엔티티 전송
PUT /sdardew.html HTTP/1.1
Host: tistory.com
Content-type: text/html
Content-Length: 1024
HEAD
- 메시지 헤더 취득
- GET과 유사하나 메시지 바디는 돌려주지 않음
- URI 유효성 검사와 리소스 시간을 확인 등의 용도로 사용
HEAD /sdardew.html HTTP/1.1
Host: tistory.com
DELETE
- 파일 삭제
- URI 리소스를 삭제
- 보안상 문제가 있어 특수한 경우 사용
DELETE /sdardew.html HTTP/1.1
Host: tistory.com
OPTIONS
- URI의 리소스가 제공하는 메서드 조회
<Request>
OPTIONS * HTTP/1.1
Host: tistory.com
<Reponse>
HTTP /1.1 200 OK
Allow: GET, POST, OPTIONS
TRACE
- 경로 조사
- 루프백(loop-back): 자신에게 통신을 되돌려 받음
- Max-Forwards: 헤더 필드에 포함되어 서버를 통과할 때마다 값이 감소
- Max-Forwards가 0이 된 곳에서 200 OK를 되돌려 줌
- 보안상의 문제로 일반적으로 사용되지 않음
TRACE / HTTP /1.1
Host: tistory.com
Max-Forwards: 5
CONNECT
- 프록시에 터널링 요구
- 양식: CONNECT 프록시 서버 : 포트 HTTP 버전
CONNECT PROXY.tistory.com:8080 HTTP /1.1
Host: tistory.com
지속 연결
- 한 쪽이 연결을 종료하지 않으면 연결이 지속됨
- TCP가 지속 연결이 아닌 경우, 데이터가 크기가 크다면 전송을 위해 연결과 종료를 반복
- HTTP/1.1과 HTTP/1.0 의 일부는 지속 연결을 제공
지속 연결의 장점
- 연결과 종료로 발생하는 오버헤드로 인한 서버의 부하가 줄어듬
- 웹 페이지의 속도가 빨라짐
파이프라인화
- 응답을 기다리지 않고 전송
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- 네이버 2022 공채
- Kotlin
- 코틀린
- go 특징
- DGS Framework
- postman collection
- squash merge
- 2차 인터뷰
- graphql
- postman tests
- mysql
- java
- 확장 함수
- postman
- solidity
- python3
- downTo
- github
- Squash and merge
- Python
- 코딩테스트
- string
- 주생성자
- Kotlin In Action
- 1차 인터뷰
- hashcode
- pm.test
- git
- pm.expect
- Basic Type
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
글 보관함