[HTTP] HTTP 통신

JJBIN·2024년 3월 26일

HTTP

목록 보기

1/6

1. HTTP

HTTP(HyperText Transfer Protocl)란 웹 상에서 정보를 주고받을 수 있는 프로토콜이다.
HTML 파일과 같은 하이퍼 미디어 문서를 전송하기 위해 고안되었다.
OSI 7계층 중 어플리케이션 레이어에 해당한다.

1) 웹과 HTTP

하나의 웹 페이지는 HTML(HyperText Markup Language), 이미지, 오디오 파일 등의 자원(Resource)을 참조하는 하나의 HTML 파일로 이루어진다.
이러한 자원들은 서로 다른 웹 서버들에 저장될 수 있다.

웹 페이지를 구성하는 HTML 파일은 URL(Uniform Resource Locator)을 통해 자원을 참조한다.

host는 자원이 저장된 서버를, path는 해당 리소스가 위치한 경로를 나타낸다.

2) 특징

A. 클라이언트 서버 모델

HTTP 통신 주체는 HTTP 요청(request)을 보내는 브라우저인 클라이언트와 요청받은 자원을 응답(response)하는 웹 서버로 구성된다.

B. TCP 연결

HTTP 통신은 주로 TCP 연결을 통해 이루어진다. (HTTP 3는 UDP를 사용)

클라이언트가 80번 포트를 사용해 서버와 소켓 연결(TCP)을 시도한다.
서버와 연결되면 클라이언트는 소켓을 통해 HTTP 요청 메시지를 전송한다.
서버는 클라이언트가 자원을 HTTP 응답 메시지에 담아 전달한다.

C. 무상태성

서버는 클라이언트에 대한 상태를 유지하지 않는다. (stateless)

장점

서버는 클라이언트의 각 요청을 독립적으로 처리한다.
하나의 요청이 실패하더라도 시스템 전체에 영향을 미치지 않는다.
시스템을 수평 확장하는 데 유리하다.

단점

클라이언트는 각 요청마다 필요한 정보를 모두 서버에게 전달해야 한다.
추가적인 네트워크 오버헤드 및 보안 문제를 발생시킬 수 있다.
로그인과 같은 사용자 상태를 유지하기가 어렵다.

2. HTTP 메시지

HTTP 메시지는 크게 헤더와 바디로 구분된다.
헤더는 키-값 쌍의 형태로 이루어져 있으며 요청이나 응답에 대한 부가적인 정보를 나타낸다.
바디는 요청이나 응답에 포함될 데이터를 나타낸다. 바디는 없을 수도 있다.

1) Request Message

HTTP 요청 메시지 형식은 아래와 같다.

요청 시작 라인에 메소드와 자원의 경로인 URL. HTTP 버전을 입력한다.
이후 한 줄에 하나씩 헤더를 입력한다.
만약 바디가 존재한다면 한줄을 띄우고(CRLF) 바디를 입력한다.

위 HTTP 메시지의 첫줄과 Host 헤더를 보면 HTTP1.1을 사용하여 www-net-cs.umass.edu(도메인네임)에게 /index.html에 위치한 자원 조회(GET)를 요청한다는 것을 알 수 있다.

2) Response Message

첫 번째 라인을 제외하면 요청 메시지와 동일한 구성이다.
시작 라인은 HTTP 버전과 상태코드로 이루어진다.

업로드중..

3) 상태 코드

서버는 상태 코드를 통해 요청의 결과를 나타낸다.

HTTP 상태 코드는 세 자리 숫자로 이루어지며 5개의 그룹으로 나뉜다.

1xx (Informational): 요청이 수신되었고 처리가 진행 중
2xx (Success): 요청이 성공적으로 처리되었음
3xx (Redirection): 요청을 완료하기 위해 클라이언트의 추가 동작이 필요
4xx (Client Error): 클라이언트 요청에 오류가 있어 요청을 처리하지 못함
5xx (Server Error): 서버 오류로 요청을 처리하지 못함

자주 사용되는 상태 코드에 대해 알아보자

A. 2XX (Success)

200 OK
- 요청이 성공적으로 완료됨
201 Created
- 요청이 완료되어 새로운 리소스가 생성됨
- POST, PUT
202 Accepted
- 서버가 요청을 접수했지만 아직 처리되지 않음
- 비동기 요청에 대한 처리를 위한 응답
204 No Content
- 요청이 성공적으로 수행되었으며, 응답 body에 반환할 값이 없음
- ex) DELETE - 자원을 삭제하여 반환할 응답 값이 없을 때
- ex) PUT, PATCH - 수정 요청의 결과가 기존과 동일하여 변경된 내용이 없을 때

B. 3XX (Redirection)

A) 로컬 캐시로 리다이렉션

304 Not Modified
- 리소스가 수정되지 않았음
- 캐싱을 목적으로 사용
  - 응답에 바디를 포함하면 안됨 (로컬 캐시에서 데이터를 가져와야 하므로)
- 특정 헤더를 포함한 조건부 GET, HEAD 요청 시 사용

B) 영구적인 리다이렉션 : 리소스의 URI가 영구적으로 변경됨

301 Moved Permanently
- 요청 메서드가 GET으로 변하고 본문이 변경될 수도 있음
308 Permanent Redirect
- 301과 유사
- 요청 메서드와 본문이 변경되지 않음을 보장
- POST와 같이 리다이렉션 후에도 유지해야 하는 데이터가 있는 경우 사용

C) 일시적인 리다이렉션 : 리소스의 URI가 일시적으로 변경됨

302 Found
- 요청 메서드가 GET으로 변하고 본문이 변경될 수도 있음
303 See Other
- 요청 메서드가 GET으로 변하고 본문이 제거됨
307 Temporary Redirect
- 요청 메서드와 본문이 변경되지 않음을 보장

302의 원래 의도는 HTTP 메서드를 유지하는 것이었으나 대부분의 브라우저에서 GET메서드로 변경시킨다.
따라서 모호한 302보다 의도가 명확한 303이나 307을 사용하는 것을 권장한다.

D) PRG (Post/Ridirect/Get) : 요청 메서드를 GET으로 변경하는 이유

POST후에 브라우저를 새로고침하면 POST가 다시 전송될 수 있다.

상품 주문 후 새로고침으로 중복 주문 등의 문제 발생

POST후에 리다이렉트를 통해 메서드를 GET으로 바꿔주면 새로고침을 하더라도 GET이 호출되어 POST의 중복 호출을 방지할 수 있다.

C. 4XX (Client Errors)

400 Bad Request
- 클라이언트의 잘못된 요청으로인해 서버에서 처리할 수 없음
- API스펙과 맞지 않은 요청시 발생
401 Unauthorized
- 인증이 안돼 자원을 이용할 수 없는 상태
- 상태코드명은 Unauthorized(미인가)이지만 실제 의미하는 바는 Unathenticated(미인증)
403 Forbidden
- 자원은 존재하지만 권한이 없어 서버에서 요청을 거절한 상태
- 401은 인증이 안된 상태(누구인지 식별할 수 없음), 403은 권한이 없는 상태(누구인지 식별은 되지만 권한은 없음)
- ex)다른 유저의 개인정보 열람
404 Not Found
- 요청한 자원이 존재하지 않는 경우
- 혹은 서버에서 자원을 숨기고 싶을 때 사용
405 Method Not Allowed
- 자원(URI)은 존재하지만 해당 자원이 지원하지 않는 메소드인 경우
- ex) users/1에 대해 DELETE메서드를 지원하지 않는 경우
- 응답의 Allow헤더에 허용되는 메서드를 포함하기도 함
409 Conflict
- 클라이언트의 해당 요청 처리 중 비즈니스 로직 상 충돌(모순)이 발생
- ex) 이메일은 중복될 수 없다는 비즈니스 로직이 존재하는 경우
429 Too Many Requests
- 클라이언트가 일정 시간 동안 너무 많은 요청을 보낸 경우

4) HTTP Method

HTTP 메서드는 각 요청이 어떻게 처리되어야 하는지를 서버에게 알려준다.

A. GET Method

reqeust

GET /search?keyword=hi&page=1 HTTP/1.1
...

respons

HTTP/1.1 200 OK
Content-Type: text/html
...

data data ...

지정된 자원을 요청한다.
서버에 데이터를 전달하고 싶은 경우 쿼리스트링을 사용한다.
Body를 사용할 수 없는 것은 아니나 권장하지 않는다. 쿼리 스트링이나 경로변수을 사용하자.

Path Variable(경로 변수)
- Resource의 계층 구조를 표현. /users/{id}
- 경로 자체에 필터링 기준이 포함. 의미있는 URL, 직관적인 구조
- URL의 일부로 캐싱에 활용
Qurey String(Query Parameter)
- Resource를 필터링 하거나 정렬하는데 사용
- 더 단순하고 간결한 URL /users?id=1
- 쿼리 파라미터 값이 다르면 다른 캐시 키로 처리될 수 있음
- URL구조에 큰 영향을 주지 않고도 추가적인 필터링이나 정렬 기능 추가 가능

path variable : 리소스 식별이 중요하고, 계층 구조를 나타내는 경우 적합
qurey parameter : 추가적인 필터링이나 정렬 기능을 제공할 때 유용

B. POST Method

request

POST /posts HTTP/1.1
Content-Type: application/json
...

{
	"title": "글 제목",
    "content": "글 내용"
}

response

HTTP/1.1 201 created
Content-Type: application/json
...

{
	"id": 1
	"title": "글 제목",
    "content": "글 내용"
}

Body를 통해 요청 데이터를 전달한다.
서버는 요청 데이터를 처리한다.

POST는 새 리소스 생성 뿐만 아니라 데이터 변경, 프로세스 처리 시에도 사용할 수 있다. (애매하면 POST)

C. PUT Method

PUT /posts/1 HTTP/1.1
Content-Type: application/json
...

{
	"title" : "글 제목"
    "content": "글 내용 수정"
}

response

HTTP/1.1 200 OK
Content-Type: application/json

{
	"id": 1
	"title": "글 제목",
    "content": "글 내용 수정"
}

리소스를 수정 혹은 생성하기 위해 사용한다.
클라이언트가 리소스를 식별하여 새로운 상태와 함께 서버로 전송한다.

서버는 해당 리소스가 존재하면 대체한다. (본문을 완전히 덮어쓴다는 것에 주의하자; 전체 선택 후 붙여넣기오와 같다)
만약 리소스가 없다면 새로 생성한다.

D. PATCH Method

request

PATCH /posts/1 HTTP/1.1
Content-Type: application/json
...

{
    "content": "글 내용 수정"
}

response

HTTP/1.1 200 OK
Content-Type: application/json

{
	"id": 1
	"title": "글 제목",
    "content": "글 내용 수정"
}

리소스의 일부를 수정하기 위해 사용한다.
PUT과 달리 리소스를 부분적으로 변경한다. (body에 포함시킨 부분만 변경)

E. DELETE

request

DELETE /posts/1 HTTP/1.1
...

response

HTTP/1.1 204 No Content
...

리소스를 제거하기 위해 사용한다.

F. 멱등성

멱등(Idempotent) : 여러 번 호출해도 그 결과가 바뀌지 않는다.

f(f(x)) = f(x)

클라이언트가 같은 요청을 해도 되는가를 판단하는 근거가 된다.

서버가 TIMEOUT 등으로 정상 응답을 못주었을 때

멱등 메서드

GET : 리소스를 변경하지 않으므로 같은 결과가 조회된다.
PUT : 리소스를 완전히 덮어쓰기 때문에 같은 요청을 여러번 보내더라도 결과는 동일해야 한다.
DELETE : 삭제 요청을 여러번 해도 리소스가 삭제된다는 결과는 똑같다.

G. 기타 메서드

HEAD

GET 메서드와 유사하지만, 응답 헤더까지만 반환한다.
일반적으로 리소스가 변경되었는지 확인하고자 할 때 사용한다.

OPTIONS

대상 리소스에 대한 통신 가능 옵션(메서드) 목록을 반환한다.
서버에서 어떤 메서드가 허용되는지 확인할 수 있다.
CORS(Cross-Origin Resource Sharing)를 확인하는 데도 사용한다.

CONNECT

대상 리소스로 식별되는 서버에 대한 터널을 설정한다.
클라이언트가 프록시 서버를 통해 다른 호스트와 직접적인 TCP 연결을 설정할 수 있게 한다.

TRACE

대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행한다.
주로 디버깅 목적으로 사용되며, 요청이 서버에 어떻게 도달하는지 확인한다.

References

James Kurose, Keith Ross, 『Computer Networking: A Top-Down Approach 7th Edition』
김영한, 『모든 개발자를 위한 HTTP 웹 기본 지식』, 인프런
인파, 『3XX (Redirection) 상태 코드 - 총정리 모음』

JJBIN

다음 포스트

[HTTP] HTTP 통신

HTTP

1. HTTP

1) 웹과 HTTP

2) 특징

A. 클라이언트 서버 모델

B. TCP 연결

C. 무상태성

2. HTTP 메시지

1) Request Message

2) Response Message

3) 상태 코드

A. 2XX (Success)

B. 3XX (Redirection)

A) 로컬 캐시로 리다이렉션

B) 영구적인 리다이렉션 : 리소스의 URI가 영구적으로 변경됨

C) 일시적인 리다이렉션 : 리소스의 URI가 일시적으로 변경됨

D) PRG (Post/Ridirect/Get) : 요청 메서드를 GET으로 변경하는 이유

C. 4XX (Client Errors)

4) HTTP Method

A. GET Method

B. POST Method

C. PUT Method

D. PATCH Method

E. DELETE

F. 멱등성

멱등 메서드

G. 기타 메서드

HEAD

OPTIONS

CONNECT

TRACE

References

[HTTP] HTTP 인증

0개의 댓글