오늘도 개발
HTTP(HyperText Transfer Protocol) 본문
1. HTTP란?
서버와 클라이언트가 데이터를 주고받을 때 사용하는 규칙이다.
HTTP는 HyperText Transfer Protocol의 약자로
하나씩 풀어보면 HTML 전송 규칙이라는 뜻이 된다.
(하지만 HTML 문서 이외에도 다양한 정보를 주고받을 수 있다.)
- HyperText : HTML(HyperText Markup Language)의 줄임말
- Transfer : 전송
- Protocol : 규칙
HTTP는 TCP/IP 기반 프로토콜 스택의 응용 계층(application layer)에 존재한다.
2. HTTP의 특징
1) Request, Response (요청, 응답)
HTTP 통신은 요청과 응답으로 이루어진다.
클라이언트가 서버에게 보내는 메시지를 request(요청),
서버가 클라이언트에게 보내는 메시지를 response(응답)이라고 한다.
HTTP의 흐름은 다음과 같다.
1) 클라이언트가 TCP 커넥션을 연다.
2) 클라이언트가 서버에게 특정 HTML 문서를 달라고 request 메시지를 보낸다.
3) 서버가 클라이언트에 response 메시지와 HTML 문서를 보낸다.
4) 클라이언트의 브라우저가 HTML 문서를 로드해서 사용자에게 보여준다.
5) 클라이언트가 TCP 커넥션을 닫거나 다른 요청에 또 사용한다.
2) Stateless
HTTP는 상태를 저장하지 않기 때문에 Stateless하다고 한다.
각각의 HTTP통신(요청, 응답)은 이전 통신에서 무슨 일이 일어났는지 모르며
각 HTTP 통신은 다른 HTTP 통신과 독립적으로 존재한다.
따라서 HTTP로 통신을 할 때는 매 통신마다 필요한 모든 정보를 담아서 요청해야 한다.
예를 들어 다음과 같이 요청하면 문제가 생긴다.
HTTP 통신 1)
클라이언트 : 로그인 했습니다.
서버 : 알았습니다.
HTTP 통신 2)
클라이언트 : 장바구니 페이지를 주세요.
서버 : 로그인해야 합니다.
두 번째 HTTP 통신은 첫 번째 통신에서 무슨 일이 일어났는지 알 수 없기 때문에
또 로그인해야 한다고 응답했다.
이를 해결하려면 두 번째 통신을 할 때도 첫번째 통신의 내용을 모두 넣어서 주어야 한다.
HTTP 통신 1)
클라이언트 : 로그인 했습니다.
서버 : 알았습니다.
HTTP 통신 2)
클라이언트 : 로그인 했습니다. 장바구니 페이지를 주세요.
서버 : 알았습니다. 여기 장바구니 페이지를 드릴게요.
이렇게 연속된 데이터 처리가 필요한 경우 같은 정보를 계속 보내는 수고를 덜기 위해
로그인 토큰, 브라우저의 쿠키, 세션, 로컬스토리지같은 기술이 등장했다.
3. Request / Response
Request(요청)
클라이언트 컴퓨터가 서버에게 보내는 메시지.
Start Line, Headers, Body로 구성된다.
1) Start Line : 요청의 첫번째 줄
GET /login HTTP/1.1
# GET 메소드로 /login 이라는 주소에 HTTP 1.1 버전으로 요청을 보내겠다
- HTTP Method : 클라이언트가 실행하려 하는 동작을 정의함. GET, POST, DELETE 등
- Request target(Path) : 요청을 보낼 url. 편지로 치면 수신인 주소를 적는 곳.
- HTTP Version : 사용된 HTTP 버전
2) Headers : 해당 요청에 대한 추가 정보(메타 데이터)를 담는 부분
딕셔너리 형태로 작성된다.
Headers: {
Host: www.apple.com
User-Agent: chrome
Content-Type: json
Content-Length: 40
Authorization:
}
- Host : 요청을 보낼 url
- User-Agent : 클라이언트 브라우저에 대한 정보(ex. chrome, firefox ...)
- Content-Type : 해당 요청 body의 타입(ex. application, json ...)
- Content-Length : body의 길이
- Authorization : 회원의 인증/인가를 처리하기 위한 로그인 토큰
3) Body : 해당 요청의 실제 내용
주로 POST 메서드인 경우 사용함
Body: {
"user_email":"sue@sue.com" "user_password": "1234"
}
Response(응답)
request를 받은 서버가 클라이언트에게 보내는 메시지.
Status Line, Headers, Body로 구성된다.
1) Status Line : 응답의 상태를 나타내는 줄
- HTTP Version : 사용된 HTTP 버전
- Status Code : 응답 메시지의 상태를 나타내는 코드
- Status Text : 응답 메시지의 상태를 간략하게 나타내는 텍스트
HTTP/1.1 404 Not Found
# HTTP 1.1 버전으로 응답하겠다
# 클라이언트에서 보낸 요청에 맞는 정보를 찾을 수 없다
2) Headers : 해당 요청에 대한 추가 정보(메타 데이터)를 담는 부분. 요청 헤더와 동일한 구조
3) Body : 해당 응답의 실제 내용
데이터를 전송할 필요가 없는 경우 생략 가능.
주로 JSON으로 작성.
Body: {
"message": "SUCCESS"
"id": "sue"
}
4. Status Code
Response 메시지의 상태를 나타내는 코드를 더 자세히 살펴보자.
200번대 - 성공
200: OK - 서버가 문제없이 요청을 처리했음
201: Created - 잘 생성했음(주로 POST 메소드 요청에 응답할 때 사용)
204: No Content - 요청 성공했음, 제공할 응답메시지 없음(주로 DELETE 메소드 요청에 응답할 때 사용)
400번대 - 클라이언트쪽의 에러
400: Bad Request - 요청을 잘못 보냈음(주로 요청의 Body가 잘못된 경우 사용)
401: Unauthorized - 요청을 진행하려면 로그인이나 회원가입이 필요함(ex. 좋아요 기능은 회원만 사용가능)
403: Forbidden - 로그인은 된 유저인데 권한이 없기 때문에 요청을 진행할 수 없음 (ex. 유료회원 컨텐츠에 접근)
404: Not Found - 요청된 URL가 존재하지 않음
500번대 - 서버쪽의 에러
500: Internal Server Error - 서버에서 에러가 났음
5. 프록시
클라이언트에서 HTTP 메시지를 보내면 사실 수많은 컴퓨터와 프로그램을 거쳐 서버에 전달된다.
클라이언트와 서버 사이에 존재하는 모든 것을 통틀어 프록시라고 부른다.
프록시는 메시지를 전달하기만 할 때도 있지만 메시지에 적극적으로 관여하기도 한다.
프록시를 캐시로 사용하거나 악성 유저를 필터링하는 데 사용할 수도 있다.
- Cache( = Web cache, HTTP cache)란?
서버가 보낸 HTTP response 메시지를 임시로 저장하는 곳.
캐시를 사용하면 같은 HTTP response 메시지를 또 보내야 할 때,
서버와 통신할 필요 없이 캐시에 저장된 HTTP response 메시지를 바로 보내면 되므로
웹페이지 로딩 속도를 높일 수 있다.
참고자료
'웹 프로그래밍 > 웹의 이해' 카테고리의 다른 글
| URI와 URL의 차이 (0) | 2022.06.04 |
|---|---|
| OSI 참조 모델과 TCP/IP (0) | 2022.05.26 |
| 2. 웹의 개요 (0) | 2022.05.24 |
| 1. 인터넷의 개요 (0) | 2022.05.22 |
| HTML, CSS, Javascript의 역할 (0) | 2022.05.18 |
