HTTP의 사전적 의미
하이퍼텍스트 전송 프로토콜(HTTP) 은 HTML과 같은 하이퍼미디어 문서를 전 송하기 위한 애플리케이션 레이어 프로토콜이다. 웹 브라우저와 웹 서버 간의 커뮤니케이션을 위해 디자인되었지만, 다른 목적으로도 사용될 수 있다. HTTP는 클라이언트가 요청을 생성하기 위한 연결을 연 다음 응답을 받을 때까지 대기하는 전통적인 클라이언트-서버 모델을 따른다. HTTP는 무상태 프로토콜이며, 이는 서버가 두 요청 간에 어떠한 데이터(상태)도 유지하지 않음을 의미한다.
HTTP의 흐름
클라이언트가 서버와 통신하고자 할 때, 최종 서버가 됐든 중간 프록시가 됐든, 다음 단계의 과정을 수행한다:
- TCP 연결을 연다:TCP 연결은 요청을 보내거나(혹은 여러개의 요청) 응답을 받는 데 사용된다. 클라이언트는 새 연결을 열거나, 기존 연결을 재사용하거나, 서버에 대한 여러 TCP 연결을 열 수 있다.
- HTTP 메시지를 전송한다다: HTTP 메시지(HTTP/2 이전의)는 인간이 읽을 수 있다. HTTP/2에서는 이런 간단한 메시지가 프레임 속으로 캡슐화되어, 직접 읽는 게 불가능하지만 원칙은 동일하다.
- 서버에 의해 전송된 응답을 읽어들인다.
- 연결을 닫거나 다른 요청들을 위해 재사용한다.
Request(요청)
GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: ko-KR
첫 번째 줄은 start line이라고 부르며 요청이나 응답의 상태를 나타내기도 한다 아래의 메시지에는 GET/HTTP/1.1이라고 나와있는데
왼쪽부터 설명하자면 GET 요청이며 프로토콜은 HTTP이며 버전은 1.1을 가리킨다.
그다음 줄은 HTTP headers이며 요청을 지정하거나 메시지에 포함된 내용을 설명하는 헤더들이라고 볼 수 있다.
Host는 당연히 요청한 사이트의 도메인이다
Accept-Language는 클라이언트가 지원하는 언어의 종류를 표시하는 것이다
Response(응답)
HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html
<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
첫 번째 줄은 똑같이 start line이며 200 OK는 응답이 성공이라는 상태 코드이다.
Date는 응답의 타임스탬프이다.
Server은 Apache라고 나와있는데 nginx가 될 수 도있고 elb나 cafe24 등등 이 될 수 있다.
Last-Modified는 브라우저가 서버로 요청한 파일의 최종 수정 시간을 알려주는 헤더, Last-Modified 헤더를 쓸 경우 브라우저가 다음에 다시 접속할 때 서버에게 파일이 또 수정되었는지 여부를 물어보게 되는데 이때 서버가 수정 여부를 내려주는 헤더가 If-Modified-Since 헤더임, 이 헤더를 사용해 캐싱을 해 성능을 향상할 수 있는데 이미지/CSS/JS와 같은 정적 파일들은 아파치에서 자동적으로 Last-Modified, If-Modified-Since헤더를 붙여준다. php 파일과 같은 동적 파일들에는 로직상에서 헤더를 붙여주면 된다.
ETag 헤더는 If-None-Match 헤더와 함께 쓰이며 If-None-Match헤더는 Etag값과 매칭 하지 않는지 판단하는 헤더이다. 아파치에서는 이미지/CSS/JS와 같은 정적 파일은 자동으로 ETag 헤더를 붙여준다. 동적 파일들에 ETag 헤더를 사용하고 싶을 때는 리소스의 갱신 일시, 사이즈 등을 계산하는 식으로 쓸 수 있다.(식별번호)
Accept-Range 헤더는 웹서버로부터 대용량의 파일을 다운로드하는 도중 중간에 끊기는 경우에 우리는 파일을 다시 처음부터 받아야 하나 아니면 중간부터 다시 받는 게 좋은가 당연히 이전에 받았던 내용을 참고하여 끊긴 부분부터 다시 연속해서 받을 수 있다면 베스트 일 것이다. 바로 이러한 경우를 가능케 하는 것이 Range 헤더이다.
Content-Length 헤더는 요청과 응답 메시지의 본문 크기를 바이트 단위로 표시해주며, 메시지 크기에 따라 자동으로 만들어진다.
Content-Type 헤더는 콘텐츠의 타입(MIME)과 문자열 인코딩(utf-8 등등)을 명시할 수 있다. 위에 예시로 든 헤더는 현재 메시지 내용이 text/html 타입이고 따로 인코딩 되는 문자열은 utf-8 문자열임을 알려준다. 프런트엔드에서 서버로 데이터를 보낼 때는 text/html 이런 것 대신 www-url-form-encoded나 multipart/form-data 같은 게 Content-Type이 된다.
아래줄은 html인데 이 부분은 body라고 부르며 html 뿐만 아니라 이미지, 영상, json 등 byte로 표현할 수 있는 데이터가 전송된다.
그 외에 많은 헤더들이 있는데 헤더들이 무조건 필수 사항이 아니라는 걸 알려주고 싶다 형식에 맞게 사용된다는 점을 알았으면 좋겠다
HTTP 메서드의 종류와 특징
HTTP 메서드는 총 9개가 있으며 먼저 주요 메소드 5개먼저 살펴보겠다.
- GET: 특정한 리소스를 가져오도록 요청한다. GET 요청은 데이터를 가져올 때만 사용해야 한다.
- POST: 서버로 데이터를 전송한다. 요청 본문의 유형은 Content-Type 헤더로 나타낸다.
- PUT: 요청 페이로드를 사용해 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 대체한다.
- DELETE: 지정한 리소스를 삭제합니다.
- PATCH: 리소스의 부분적인 수정을 할 때에 사용됩니다.
나머지 4개의 메소드
- CONNECT: 요청한 리소스에 대해 양방향 연결을 시작하는 메서드이며 터널을 열기 위해서 사용될 수 있다.
- HEAD: 특정 리소스를 GET 메서드로 요청했을 때 돌아올 헤더를 요청한다.
- OPTIONS: 웹서버에서 지원되는 메서드의 종류를 확인할 경우 사용한다.
- TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행하여 유용한 디버깅 메커니즘을 제공한다.
HTTP 메서드와 CRUD의 상관관계
클라이언트가 서버에 데이터를 요청할 때 CRUD라는 4가지 타입이 있는데 CRUD는 Create(쓰기), Read(읽기), Update(수정), Delete(삭제)를 말한다 HTTPS와 연결하자면 아래의 그림으로 나타낼 수 있을 거 같다.
HTTP Methods | CRUD |
POST | Create |
GET | Read |
PUT | Update |
DELETE | Delete |
POST와 PUT의 차이점은 무엇인가
둘의 차이점으로는 멱등성이라고 할 수 있는데 멱등성이란 사전적 의미로서는 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질, 연산을 여러 번 반복하여도 한 번만 수행된 것과 같은 성질을 의미하는데 이걸 연결해서 얘기하자면 POST메서드는 여러번 요청을 하게되면 계속해서 새로운 리소스를 생성해내기 때문에 연속으로 요청한다해서 같은 요청이 반복되지 않는다는것이다. 하지만 PUT 메소드는 아무리 연속적으로 요청해도 리소스 위치가 고정되어있기 때문에 멱등하다라고 얘기할 수 있다.
HTTP 응답 코드의 특징과 차이점
2XX : Successful responses
200 OK: 요청이 성공적으로 되었음
201 Created: 요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었음. 이 응답은 일반적으로 POST 요청 또는 일부 PUT 요청 이후에 따라온다.
202 Accepted: 요청을 수신하였지만, 그에 응하여 행동할 수 없다. 이 응답은 요청 처리에 대한 결과를 이후에 HTTP로 비동기 응답을 보내는 것에 대해서 명확하게 명시하지 않는다.
203 Non-Authoritative Information: 이 응답 코드는 돌려받은 메타 정보 세트가 오리진 서버의 것과 일치하지 않지만 로컬이나 서드 파티 복사본에서 모아졌음을 의미한다. 이러한 조건에서는 이 응답이 아니라 200 OK 응답을 반드시 우선된다.
204 No Content: 요청에 대해서 보내줄 수 있는 콘텐츠가 없지만, 헤더는 의미 있을 수 있다. 사용자-에이전트는 리소스가 캐시 된 헤더를 새로운 것으로 업데이트할 수 있다.
205 Reset Content: 이 응답 코드는 요청을 완수한 이후에 사용자 에이전트에게 이 요청을 보낸 문서 뷰를 리셋하라고 알려준다.
206 Partial Content: 이 응답 코드는 클라이언트에서 복수의 스트림을 분할 다운로드를 하고자 범위 헤더를 전송했기 때문에 사용됩니다. 클라이언트가 이어받기를 시도하면 웹서버가 이에 대한 응답 코드로 '206 Partial Content'와 함께 Range 헤더에 명시된 데이터의 부분(byte)부터 전송을 시작한다.
3XX : Redirection messages
300 Multiple Choice: 요청에 대해서 하나 이상의 응답이 가능하다.
301 Moved Permanently: 이 응답 코드는 요청한 리소스의 URI가 변경되었음을 의미한단다. 새로운 URI가 응답에서 아마도 주어질 수 있다.
302 Found: 이 응답 코드는 요청한 리소스의 URI가 일시적으로 변경되었음을 의미한다. 새롭게 변경된 URI는 나중에 만들어질 수 있습니다. 그러므로, 클라이언트는 향후의 요청도 반드시 동일한 URI로 해야 한다.
303 See Other: 클라이언트가 요청한 리소스를 다른 URI에서 GET 요청을 통해 얻어야 할 때, 서버가 클라이언트로 직접 보내는 응답이다.
304 Not Modified: 이것은 캐시를 목적으로 사용된다. 이것은 클라이언트에게 응답이 수정되지 않았음을 알려주며, 그러므로 클라이언트는 계속해서 응답의 캐시 된 버전을 사용할 수 있다.
305 Use Proxy: 이전 버전의 HTTP 기술 사양에서 정의되었으며, 요청한 응답은 반드시 프락시를 통해서 접속해야 하는 것을 알려준다.
307 Temporary Redirect: 클라이언트가 요청한 리소스가 다른 URI에 있으며, 이전 요청과 동일한 메서드를 사용하여 요청해야 할 때, 서버가 클라이언트에 이 응답을 직접 보낸다. 이것은 302 Found HTTP 응답 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 사용된 HTTP 메소드를 변경하지 말아야 하는 점만 다르다. 만약 첫 요청에 POST가 사용되었다면, 두 번째 요청도 반드시 POST를 사용해야 한다.
308 Permanent Redirect: 이것은 리소스가 이제 HTTP 응답 헤더의 Location:에 명시된 영구히 다른 URI에 위치하고 있음을 의미하는데 301 Moved Permanently HTTP 응답 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 HTTP 메소드를 변경하지 말아야 하는 점만 다르다. 만약 첫 요청에 POST가 사용되었다면, 두번째 요청도 반드시 POST를 사용해야 한다.
4XX : Client error responses
400 Bad Request: 이 응답은 잘못된 문법으로 인하여 서버가 요청하여 이해할 수 없음을 의미한다.
401 Unauthorized: 비록 HTTP 표준에서는 '미승인(unauthorized)'를 명확히 하고 있지만, 의미상 이 응답은 '비인증(unauthenticated)'를 의미합니다. 클라이언트는 요청한 응답을 받기 위해서는 반드시 스스로를 인증해야 한다.
402 Payment Required: 이 응답 코드는 나중에 사용될 것을 대비해 예약되어있다.
403 Forbidden: 클라이언트는 콘텐츠에 접근할 권리를 가지고 있지 않다. 예를 들어, 그들은 미승인이어서 서버는 거절을 위한 적절한 응답을 보낸다. 401과 다른 점은 서버가 클라이언트가 누구인지 알고 있다.
404 Not Found: 소스를 찾을 수 없다. 브라우저에서는 알려지지 않은 URL을 의미한다. 이것은 API에서 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수 있다. 서버들은 인증받지 않은 클라이언트로부터 리소스를 숨기기 위하여 이 응답을 403 대신에 전송할 수도 있다.
5XX : Server error responses
500 Internal Server Error: 웹 사이트 서버에 문제가 있음을 의미하지만 서버는 정확한 문제에 대해 더 구체적으로 설명할 수 없다.
501 Not Implemented: 서버가 요청을 이행하는 데 필요한 기능을 지원하지 않음을 나타낸다.
502 Bad Gateway: 서버가 게이트웨이로부터 잘못된 응답을 수신했음을 의미합니다. 인터넷상의 서버가 다른 서버로부터 유효하지 않은 응답을 받은 경우 발생한다.
503 Service Unavailable: 서버가 요청을 처리할 준비가 되지 않았다. 일반적인 원인은 유지보수를 위해 작동이 중단되거나 과부하가 걸린 서버이다.
504 Gateway Timeout: 웹페이지를 로드하거나 브라우저에서 다른 요청을 채우려는 동안 한 서버가 액세스하고 있는 다른 서버에서 적시에 응답을 받지 못했음을 의미한다. 이 오류 응답은 서버가 게이트웨이 역할을 하고 있으며 적시에 응답을 받을 수 없을 경우 주어진다. 이 오류는 대게 인터넷상의 서버 간의 네트워크 오류이거나 실제 서버의 문제이다. (nginx 쓰면서 제일 많이 본 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ.....)
여기에 쓰인 상태 코드 말고도 많은 코드들이 있는데 MDN사이트에서 확인하면 좋을 거 같다.
기술처처
https://developer.mozilla.org/ko/docs/Web/HTTP
HTTP | MDN
하이퍼텍스트 전송 프로토콜(HTTP)_은 HTML과 같은 하이퍼미디어 문서를 전송하기위한 _애플리케이션 레이어 프로토콜입니다. 웹 브라우저와 웹 서버간의 커뮤니케이션을위해 디자인되었지만, 다
developer.mozilla.org
'DevOps > CS' 카테고리의 다른 글
[DevOps] 소켓과 포트의 특징, HTTP버전별 특징 (0) | 2022.12.28 |
---|---|
[DevOps] 데이터베이스 정규화 (0) | 2022.12.19 |
[DevOps] DNS 너 어떻게 작동하는건데!!! (0) | 2022.12.06 |
[DevOps] DevOps가 뭔지알아??? 내가알려줄게 (2) | 2022.11.29 |
[DevOps] SaaS??? 너 누구야!!! (1) | 2022.11.28 |