본 내용은 책 'HTTP 완벽 가이드'를 참고해 작성했습니다.
3-1. 메시지의 흐름
HTTP 메시지 : HTTP 애플리케이션 간에 주고 받는 데이터 블록(텍스트 메타 정보, 데이터, 클라이언트, 서버, 프락시 사이를 흐름)들을 의미
인바운드와 아웃바운드
트랜잭션의 방향을 표현하기 위해 사용하는 개념, 서버 입장의 개념
- 인바운드
- 메시지가 서버로 향하는 것
- 아웃바운드
- 메시지가 클라이언트로 돌아오는 것
3-2. 메시지의 각 부분
다운 스트림
HTTP는 강물과 같이 흐르고, 요청/응답 메시지 상관없이 모든 메시지는 다운스트림으로 흐른다.
메시지 각 부분
- 시작줄 : 어떤 메시지인지 서술
- 요청 메시지
- 메서드 요청 url 버전
- 응답 메시지
- 버전 상태 코드 사유 구절
- 200 OK, 200 NOT OK
- 요청 메시지
- 헤더
- 속성
- 시작줄과 헤더는 줄 단위로 분리된 아스키 문자열
- 각 줄은 두 글자의 줄바꿈 문자열(CRLF)로 끝남
CR : Carriage Return (\\r) LF : Line Feed (\\n) CR : 현재 커서를 줄 올림 없이 가장 앞으로 옮기는 동작 LF : 커서는 그 자리에 그대로 둔 상황에서 종이만 한 줄 올려 줄을 바꾸는 동작 - 본문
- 데이터를 담거나 아예 없을 수 있음
💡 메시지 헤더는 반드시 CRLF로 끝나야 한다. 그런데 이를 지키지 않는 경우도 있으므로 (오래되거나, 잘못된 경우)클라이언트와 서버는 CRLF가 없는 메시지도 받을 수 있어야 한다. → 잘못 오면 안됨!!!
메서드
메서드 설명 본문 여부
| GET | 서버에서 문서 가져옴 | x |
| HEAD | 서버에서 어떤 문서의 헤더만 가져옴 | x |
| POST | 서버가 처리해야 할 데이터를 전송함 | o |
| PUT | 서버에 요청 메시지의 본문을 저장함 | o |
| TRACE | 메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적함 | x |
| OPTIONS | 서버가 어떤 메서드를 수행할 수 있는지 확인함 | x |
| DELETE | 서버에서 문서를 제거함 | x |
상태 코드
서버가 클라이언트의 요청에 대한 결과를 알려주는 세자리 숫자를 의미한다.
상태 코드는 프로그램이 에러를 처리하기 쉽게 해준다.
- 상태 코드 종류전체 범위 정의된 범위 분류
| 100-199 | 100-101 | 정보 |
| 200-299 | 200-206 | 성공 |
| 300-399 | 30-305 | 리다이렉션 |
| 400-499 | 400-415 | 클라이언트 에러 |
| 500-599 | 500-505 | 서버 에러 |
- 200 : OK, 성공, 요청한 모든 데이터는 응답 본문에 들어있음
- 401 : Unauthorized, 사용자 이름과 비밀번호를 입력
- 404 : Not Found, 서버는 요청한 URL에 해당하는 리소스를 찾지 못함
사유 구절
상태코드의 사람이 이해하기 쉬운 버전
HTTP/1.0 200 OK 에서 OK가 위치한 부분을 의미
3-3. 메서드
서버는 모든 메서드를 사용해 구현하지 않는다(부스타가 GET, POST만 사용하는 것처럼)
→ 사용자가 악용할 수 있는 문제가 발생할 수 있음
1. 안전한 메서드
GET, HEAD 메서드가 해당되고, 이 메서드를 사용한 HTTP 요청을 보내도 서버에 어떠한 영향(작용)도 미치지 않는다.
안전한 메서드를 알면 안전하지 않은 메서드를 알 수 있고, 안전하지 않은 메서드를 사용할 때 서버에서 어떤 일이 일어날 수 있음을 알려주는 경고 메시지를 만들 수 있다.
2. GET
가장 흔히 쓰이는 메서드로, 주로 서버에게 리소스를 달라고 요청하기 위해 사용한다.
3. HEAD
정확히 GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려주는 메서드이다.
HEAD로 반환되는 헤더 = GET으로 반환되는 헤더
HTTP/1.1 준수를 위해서는 HEAD 메서드가 반드시 구현되어 있어야 한다.
- HEAD 메서드를 통해 얻을 수 있는 것들
- 리소스를 가져오지 않고도 리소스가 무엇인지(타입)를 알아낼 수 있음
- 응답 상태코드로 리소스 존재 여부 확인 가능
- 응답 헤더를 확인해 리소스가 변경되었는지 검사 가능
4. PUT
- 요청 body를 이용해 요청 URL의 이름대로 새 문서를 만들거나
- 이미 URL이 존재한다면 body를 사용해 교체하는 것을 의미
→ PUT은 콘텐츠를 변경할 수 있게 해주기 때문에 많은 웹 서버가 PUT을 수행하기 전에 로그인으로 사용자 식별을 선행할 것이다.
5. POST
서버에 입력 데이터를 전송하기 위해 설계된 메서드이다. 본문에 담긴 데이터가 서버로 전송되고, 서버는 이를 모아서 필요로 하는 곳으로 보낸다.
6. TRACE
주로 진단을 위해 사용되는 메서드이다. 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다(요청은 방화벽, 프락시, 게이트웨이 등 애플리케이션에 의해 수정될 수 있기 때문)
- TRACE 요청
- 본문에 어떤 엔티티도 넣어서 보낼 수 없음
- 요청 전송의 마지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답
- 클라이언트는 자신과 목적지 서버 사이에 있는 모든 HTTP 요청/응답 연쇄를 따라가며 자신이 보낸 메시지가 망가졌거나 수정되었는지, 수정되었다면 어떻게 수정되었는지 확인할 수 있음
- 용도
- 요청이 의도한 요청/응답 연쇄를 거쳐가는지 확인
- 다른 애플리케이션이 요청에 어떤 영향을 미치는지 확인
- 주의사항
- 애플리케이션 별로 TRACE 요청을 어떻게 처리하는지 방법이 다르다
7. OPTIONS
웹 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어보는 메서드이다.
여러 리소스에 실제로 접근하지 않고도 그것들을 어떻게 접근하는 것이 최선인지 확인할 수 있는 수단을 클라이언트 애플리케이션에게 제공한다.
8. DELETE
서버에게 요청 URL로 지정한 리소스 삭제를 요청하는 메서드이다.
3-4. 상태 코드
1. 100-101 : 정보성 상태 코드상태 코드 사유 구절 의미
| 100 | Continue | 요청의 시작 부분 일부가 받아들여졌고, 클라이언트는 나머지를 계속 이어서 전송해야함을 의미 |
| 101 | Switching Protocols | 서버가 프로토콜을 변경했음을 의미 |
클라이언트의 요청이 서버에 도달했고 서버가 프로세스를 진행하고 있다는 의미
- 클라이언트와 100 ContinueExpect 요청 헤더를 추가해서 요청해야 한다
- 서버가 다루거나 사용할 수 없는 큰 엔티티를 서버에게 보내지 않으려는 목적으로만 사용해야 한다
- 서버와 100 Continue
- 서버가 100-continue 값이 담긴 Expect 헤더가 포함된 요청을 받는다면, 100 continue 응답 혹은 에러코드로 응답해야 한다.
2. 200-206 : 성공 상태 코드
요청이 성공적으로 처리되었을 때의 응답 상태 코드
| 상태 코드 | 사유 구절 | 의미 |
| 200 | OK | 요청이 정상 처리 됐고, 엔티티 본문은 요청된 리소스를 포함한다. |
| 201 | Created | 서버 개체 생성 요청의 성공 응답. |
| 202 | Accepted | 요청은 받아들여졌으나 서버는 아직 그에 대한 어떤 동작도 수행하지 않았음. |
| 203 | Non-Authoritative Information | 중개자가 리소스의 사본을 갖고 있었지만, 리소스에 대한 헤더를 검증하지 못한 경우의 상태 코드. |
| 204 | No Content | 응답에 헤더와 상태줄을 포함하지만, 엔티티 본문은 포함하지 않는다는 상태 코드. 주로 웹 브라우저를 새 문서로 이동시키지 않고 갱신할 때 사용한다. |
| 205 | Reset Content | 브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우라고 말하는 상태콛. 주로 브라우저를 위해 사용된다. |
| 206 | Partial Content | 부분 혹은 범위 요청이 성공했다는 것을 알리는 상태 코드. Content-Rage, Date는 반드시 포함해야 하며 Etag, Content-Location 중 하나도 반드시 포함해야 한다. |
3. 300 - 307 : 리다이렉션 상태 코드
리다이렉션 상태 코드는 클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 다른 대안을 제공한다.
리다이렉션 상태 코드만약 리소스가 옮겨졌다면, 클라이언트에게 리소스가 옮겨졌으며 어디서 찾을 수 있는지 알려주기 위해 리다이렉션 상태 코드와 선택적으로 Location 헤더를 보낼 수 있다.
| 상태 코드 | 사유 구절 | 의미 |
| 300 | Multiple Choices | 클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청한 경우, 그 리소스의 목록과 함께 반환. |
| 301 | Moved Permanently | 요청한 URL이 옮겨졌을 때 사용. 응답은 Location 헤더에 현재 리소스가 존재하고 있는 url을 포함해야 한다. |
| 302 | Found | 요청한 URL이 옮겨졌을 때 사용. 응답에서의 Location 헤더로 주어진 url은 리소스를 임시로 가리키고 있기에 이후의 요청은 원래 url을 사용해야 한다. |
| 303 | See Other | 클라이언트에게 리소스를 다른 url에서 가져와야 한다고 말해주는 용도. 주 목적은 POST 요청에 대한 응답으로 클라이언트에게 리소스의 위치를 알려주는 용도이다. |
| 304 | Not Modified | 수정되지 않은 리소스에 대해 수정되지 않았음을 알려주는 상태 코드. |
| 305 | Use Proxy | 리소스가 반드시 프락시를 통해서 접근되어야 함을 나타내기 위해 사용. |
| 306 | 사용되지 않음 | |
| 307 | Temporary Redirect | 302와 설명 동일 |
- 302, 303, 307의 유사한 설명HTTP/1.1 위 리다이렉션을 303 상태코드로 진행하고, 307은 일시적인 리다이렉트를 위해 사용함.
- → 서버는 리다이렉트 응답에 들어갈 가장 적절한 리다이렉트 상태 코드를 선택하기 위해 클라이언트의 HTTP의 버전을 검사해야 한다.
- HTTP/1.0 에서는 POST 요청에 대한 리소스의 위치를 302 코드로 전송(서버는 클라이언트가 리다이렉션 URL에 대한 GET 요청으로 리다이렉트를 따라가길 기대함)
4. 400 - 417 : 클라이언트 에러 상태 코드상태 코드 사유 구절 의미
| 상태 코드 | 사유 구절 | 의미 |
| 400 | Bad Request | 클라이언트가 잘못된 요청 보냄 |
| 401 | Unauthorized | 리소스를 얻기 전에 스스로 인증하라고 요구하는 상태코드 |
| 402 | Payment Required | 현재 쓰이지 않는 상태 코드. |
| 403 | Forbidden | 요청이 서버에 의해 거부되었음을 알려주기 위해 사용됨 |
| 404 | Not Found | 서버가 요청한 URL을 찾을 수 없음을 알려주기 위해 사용. |
| 405 | Method Not Allowed | URL에 지원하지 않은 메서드로 요청을 받았을 때 사용. 응답 헤더에 Allow 헤더가 있어야 함 |
| 406 | Not Acceptable | 주어진 url에 대한 리소스 중 클라이언트가 받아들일 수 있는게 없을 때 사용. |
| 407 | Proxy Authentication Required | 401과 동일하지만, 프락시 서버에 인증을 해야하는 경우에 사용. |
| 408 | Request Timeout | 클라이언트 요청을 완수하기에 시간이 너무 많이 걸릴 때 서버는 이 상태코드를 보내고 연결을 끝낼 수 있음 |
| 409 | Conflict | 요청이 리소스에 대해 일으킬 수 있는 몇몇 충돌을 지칭하기 위해 사용. |
| 410 | Gone | 404와 비슷하지만 서버 관리자가 클라이언트에게 기조에 있었던 리소스가 제거된 경우를 알려주기 위해 사용. |
| 411 | Length Required | 서버가 요청 헤더에 Content-Length 헤더가 있어야 함을 요구할 때 사용. |
| 412 | Precondition Failed | 클라이언트가 조건부 요청을 했는데 그중 하나가 실패했을 때 사용. |
| 413 | Request Entity Too Long | 처리 한계를 넘은 요청을 클라이언트가 전송시 사용. |
| 414 | Request URI Too Long | 처리 한계를 넘는 길이의 요청 URL이 포함된 요청을 클라이언트가 보냈을 때 사용. |
| 415 | Unsupported Media Type | 서버가 이해하거나 지원하지 못하는 내용 유형의 엔티티를 클라이언트가 보냈을 ㅅ때 사용 |
| 416 | Requested Range Not Satisfiable | 리소스의 특정 범위를 요청했는데 그 범위가 잘못되거나 맞지 않을 때 사용. |
| 417 | Expectation Failed | 요청에 포함된 Expect 요청 헤더에 서버가 만족시킬 수 없는 기대가 담겨있는 경우 사용. |
5. 500 - 505 : 서버 에러 상태 코드상태 코드 사유 구절 의미
클라이언트가 올바른 요청을 보냈음에도 서버 자체에서 에러가 발생하는 경우가 있는데, 그때 사용하는 상태 코드이다.
| 상태 코드 | 사유 구절 | 의미 |
| 500 | Internal Server Error | 서버가 요청을 처리할 수 없게 만드는 에러를 만났을 때 사용 |
| 501 | Not Implemented | 클라이언트가 서버의 능력을 넘는 요청을 했을 때 사용(서버가 지원하지 않는 메서드 사용) → Method Not Allowed 아닌가? |
| 502 | Bad Gateway | 자신의 부모 게이트웨이에 접속하는 것이 불가능할 때 사용하는 코드 |
| 503 | Service Unavailable | 현재는 서버가 요청을 처리해 줄 수 없지만, 나중에는 가능함을 의미하는 코드. Retry-After헤더를 응답에 포함해 전송 |
| 504 | Gateway Timeout | 상태코드 408과 비슷함. 게이트웨이나 프락시에서 타임아웃이 발생해서 온 응답이라는 것에서 다름. |
| 505 | HTTP Version Not Supported | 서버가 지원할 수 없거나 지원하지 않으려고 하는 버전의 프로토콜로 된 요청을 받았을 때 사용. |
3-5. 헤더
쿠키랑 인증키만 기억하면 됨!!!
일반 헤더
클라이언트와 서버 양쪽 모두가 사용하는 헤더이고, 메시지에 대한 아주 기본적인 정보를 제공한다. 메시지 종류에 상관없이 유용한 정보를 제공한다.
| 헤더 | 설명 |
| Connection | 요청/응답 연결에 대한 옵션 정할 수 있게 해줌 |
| Date | 메시지가 언제 만들어졌는지에 대한 날짜와 시간 제공 |
| MIME-Version | 발송자가 사용한 MIME의 버전을 알려줌 |
| Trailer chunked transfer | 인코딩으로 인코딩된 메시지의 끝 부분에 위치한 헤더들의 목록을 나열 |
| Transfer-Encoding | 수신자에게 안전한 전송을 위해 메시지에 어떤 인코딩이 적용되었는지 말해줌 |
| Upgrade | 발송자가 ‘업그레이드’하길 원하는 새 버전이나 프로토콜을 알려줌 |
| Via | 이 메시지가 어떤 중개자(프락시, 게이트웨이)를 거쳐 왔는지 보여줌 |
- 일반 캐시 헤더
HTTP/1.0은 매번 서버로부터 객체를 가져오는 대신 로컬 복사본으로 캐시할 수 있는 최초의 헤더를 도입함.
| 헤더 | 설명 |
| Cache-Control | 메시지와 함께 캐시 지시자를 전달하기 위해 사용함 |
| Pragma | 메시지와 함께 지시자를 전달하는 또 다른 방법. 캐시에 국한되지 않음. 엄밀히 말하면 요청 헤더. deperecated 될 예정. |
요청 헤더
요청 메시지에서만 의미를 갖는 헤더이다.
| 헤더 | 설명 |
| Client-IP | 클라이언트가 실행된 컴퓨터 IP 제공 |
| From | 클라이언트 사용자의 메일 주소 제공 |
| Host | 요청의 대상이 되는 서버의 호스트 명과 포트 제공 |
| Referer | 현재의 요청 URI가 들어있던 문서의 URL 제공 → URL의 URL? |
| UA-Color | 클라이언트 기기 디스플레이의 색상 능력 정보 제공 |
| UA-CPU | 클라이언트 CPU 종류나 제조사 알려줌 |
| UA-Disp | 클라이언트 디스플레이 능력에 대한 정보 제공 |
| UA-OS | 클라이언트 기기에서 동작 중인 os 이름과 버전 제공 |
| UA-Pixels | 클라이언트 기기 디스플에이에 대한 픽셀 정보 제공 |
| User-Agent | 요청을 보낸 애플리케이션 이름 알려줌 |
- Accept 관련 헤더
클라이언트는 Accept 관련 헤더를 이용해 서버에게 자신의 선호와 능력을 알려줄 수 있다. 이는 클라이언트와 서버 모두에 유용한 정보이고, 클라이언트는 그들이 원하는 것을 얻을 수 있고, 서버는 클라이언트가 사용할 수 없는 것을 전송하는데 시간과 대역폭을 낭비하지 않아도 된다.
| 헤더 | 설명 |
| Accept | 서버가 보내도 되는 미디어 종류 |
| Accept-Charset | 서버가 보내도 되는 문자집합 |
| Accept-Encoding | 서버가 보내도 되는 인코딩 |
| Accept-Language | 서버가 보내도 되는 언어 |
| TE | 서버가 보내도 되는 확장 전송 코딩 |
- 조건부 요청 헤더
클라이언트가 요청에 몇몇 제약을 넣기 위한 헤더이다. 조건부 요청 헤더를 사용하면 클라이언트는 서버에게 요청에 응답하기 전에 먼저 조건이 참인지 확인하게 하는 제약을 포함시킬 수 있다.
헤더 설명
| 헤더 | 설명 |
| Expect | 클라이언트가 요청에 필요한 서버의 행동 열거할 수 있게 해줌 |
| If-Match | 문서의 엔티티 태그가 주어진 엔티티 태그와 일치하는 경우에만 문서 가져옴 |
| If-Modified-Since | 주어진 날짜 이후에 리소스가 변경되지 않았다면 요청 제한 |
| If-None-Match | 문서의 엔티티 태그가 주어진 엔티티 태그와 일치하지 않는 경우에만 문서를 가져옴 |
| If-Range | 문서의 특정 범위에 대한 요청 가능 |
| If-Unmodified-Since | 주어진 날짜 이후에 리소스가 변경되었다면 요청 제한 |
| Range | 서버가 범위 요청을 지원하는 경우, 리소스에 대한 특정 범위를 요청 |
- 요청 보안 헤더 → 알아둬야 함!!!
트랜잭션을 더 안전하게 만들기 위해 클라이언트가 특정 리소스에 접근하기 전에 자신을 인증하게 할 수 있다.
| 헤더 | 설명 |
| Authorization | 클라이언트가 서버에게 제공하는 인증 그 자체에 대한 정보를 담고 있음 |
| Cookie | 클라이언트가 서버에게 토큰을 전달할 때 사용 |
| Cookie2 | 요청자가 지원하는 쿠키의 버전을 알려줄 때 사용 |
- 프락시 요청 헤더
| 헤더 | 설명 |
| Max-Forwards | 요청이 원 서버로 향하는 과정에서 다른 프락시나 게이트웨이로 전달될 수 있는 최대 횟수 |
| Proxy-Authorization | Authorization과 같으나, 프락시에서 인증을 할 때 사용 |
| Proxy-Connection | Connection과 같으나 프락시에서 연결을 맺을 때 사용 |
응답 헤더
| 헤더 | 설명 |
| Age | 응답이 얼마나 오래되었는지 의미 |
| Public | 서버가 특정 리소스에 대해 지원하는 요청 메서드 목록 |
| Retry-After | 현재 리소스가 사용 불가능한 상태일 때, 언제 가능해지는지 날짜/시각 |
| Server | 서버 애플리케이션의 이름과 버전 → 알려줄 필요 없음 |
| Title | HTML 문서에서의 제목 |
| Warning | 사유 구절에 있는 것보다 더 자세한 경고 메시지 |
- 협상 헤더
서버에 선택 가능한 여러가지 표현이 있을 경우, HTTP/1.1 은 서버와 클라이언트가 어떤 표현을 택할 것인가에 대한 협상을 할 수 있도록 지원한다.
| 헤더 | 설명 |
| Accept-Ranges | 서버가 자원에 대해 받아들일 수 있는 범위의 형태 |
| Vary | 응답에 영향을 줄 수 있는 헤더들의 목록(예시, 서버가 클라이언트에게 보내줄 리소스의 가장 적절한 버전을 선택하기 위해 살펴봐야 하는 헤더 목록) |
- 응답 보안 헤더
| 헤더 | 설명 |
| Proxy-Authentication | 프락시에서 클라이언트로 보낸 인증요구의 목록 |
| Set-Cookie | 서버가 클라이언트를 인증할 수 있도록 클라이언트 측에 토큰을 설정하기 위해 사용 → Cookie 와 Set-Cookie의 관계 알아둬야 함 |
| Set-Cookie2 | Set-Cookie와 비슷하게 RFC 2965로 정의된 쿠키 |
| WWW-Authenticate | 서버에서 클라이언트로 보낸 인증요구의 목록 |
엔티티 헤더
요청과 응답 모두 엔티티를 포함할 수 있기에 엔티티 헤더는 양쪽에서 모두 나타날 수 있다.
- 엔티티 헤더가 제공하는 정보
- 엔티티 자체와 내용에 관한 정보
- 개체의 타입 ~ 주어진 리소스에 대해 요청할 수 있는 유효한 메서드
| 헤더 | 설명 |
| Allow | 해당 엔티티에 대해 수행될 수 있는 요청 메서드들 |
| Location | 클라이언트에게 엔티티가 실제로 어디에 위치하고 있는지 알려줌. 수신자에게 리소스에 대한 위치(새로운 url)을 알려줄 때 사용 |
- 콘텐츠 헤더
엔티티 콘텐츠에 대한 구체적인 정보를 제공한다. 콘텐츠의 종류, 크기, 기타 콘텐츠를 처리할 때 유용하게 활용될 수 있는 것들이다.
| 헤더 | 설명 |
| Content-Base | 본문에서 사용된 상대 url을 계산하기 위한 기저 url |
| Content-Encoding | 본문에 적용된 인코딩 |
| Content-Language | 본문을 이해하는데 가장 적절한 자연어 |
| Content-Length | 본문의 길이/크기 |
| Content-Location | 리소스가 실제 위치하는 곳 |
| Content-MD5 | 본문의 MD5 체크섬 |
| Content-Range | 전체 리소스에서 이 엔티티가 해당하는 범위를 바이트 단위로 표현 |
| Content-Type | 엔티티의 종류 |
- 엔티티 캐싱 헤더
엔티티 캐싱에 대한 정보를 제공한다. 리소스에 대해 캐시 사본이 아직 유효한지, 캐시된 리소스가 더 이상 유효하지 않게 되는 시점을 더 잘 추정하기 위한 단서 등을 제공한다.
| 헤더 | 설명 |
| ETag | 엔티티 태그 |
| Expires | 엔티티가 만료되는 일시, 만료되면 원본을 다시 받아와야 한다. |
| Last-Modified | 엔티티가 변경된 최근 일시 |
'네트워크 > HTTP' 카테고리의 다른 글
| [HTTP] 4장 : 커넥션 관리 (2) | 2023.12.04 |
|---|---|
| [HTTP] 2장 : URL (0) | 2023.12.04 |
| [HTTP] 1장 : HTTP 개관 (0) | 2023.12.04 |