2주차 개념 스터디 - HTTP (1)

🎨 HTTP

- 거의 모든 웹 요청은 http가 기반이며 웹 서비스의 가장 핵심이다

- 그 중에서도 주요 키워드들에 대해 공부하려고 한다!

> http 1.1 / 2.0

> 상태코드

> 요청 메서드

> http vs https

> http vs tcp vs ip

 

🔴 HTTP 1.1 / 2.0

1. HTTP 1.1

- HTTP 1.1 은 기본적으로 connection 당 하나의 요청을 처리하도록 설계되어 있다

- 따라서 동시 전송 문제와 다수이 리소스를 처리하기에 속도와 성능 이슈가 존재한다

- 이로 인해 HTTP 1.1 은 HOL(Head Of Line) Blocking - 특정 응답 지연, RTT(Round Trip Time) 증가, 헤비한 Header 구조라는 문제점들을 가지고 있다

 

> HOL (Head Of Line) Blocking - 특정 응답 지연

   : 하나의 응답이 지연될 때, 해당 응답이 완료될 때까지 다음 요청은 무한 대기 상태가 된다

> RTT (Round Trip Time) 증가

   : 하나의 Connection에 하나의 요청을 처리하므로, 요청별로 Connection을 만들게 된다

   : 이로 인해, 3-way Handshake가 반복적으로 일어나게 되어 불필요한 RTT 증가와 네트워크 지연을 초래한다

> 헤비한 Header 구조

   : HTTP 1.1 헤더에는 많은 메타 정보들이 저장되는데, 사용자가 방문한 웹페이지는 다수의 HTTP 요청이 발생한다

   : 이 경우, 매 요청 시마다 중복된 헤더 값을 전송하고, 해당 도메인에 설정된 cookie 정보도 매 요청시 헤더에

     포함되므로 전송하려는 값보다 헤더 값이 더 클 수가 있다

 

1.1 HTTP 2.0 등장 전 HTTP 1.1 문제점 극복 노력

• Image Spriting : 여러 이미지 파일들에 대해 각각 요청을 하기보다 한 번에 요청으로 끝내기를 택했다. 따라서 여러 이미지를 모아 하나의 큰 이미지를 만든 후, CSS로 해당 이미지의 좌표값을 지정해서 사용했다
• Domain Sharding : 하나의 Domain에 대해 여러개의 Connection을 생성하여 병렬로 요청을 보낸다. 하지만 브라우저 별로 Domain당 Connection 개수의 제한이 존재하므로 근본적인 해결책이 될 수 없었다
• CSS, Javascript 최소화 : 전송되는 데이터 용량을 줄이기 위해 CSS, Javascript 파일을 최소화하여 통신한다

 

2. HTTP 2.0

- HTTP 2.0은 HTTP 1.1을 해결하고자 등장했으며, 성능 뿐만 아니라 속도면에서도 HTTP 1.1보다 월등하다

- 이는 Multiplexed Streams, Stream Prioritization, Server Push, Header Compression을 사용하여 선들을 향상시켰다

 

> Multiplexed Stream

• 한 커넥션에 여러 개의 메시지를 동시에 주고 받을 수 있다

 

> Stream Prioritization

• 요청 리소스간의 의존관계(우선 순위)를 설정할 수 있다
• 만약 css 파일이 다른 리소스 파일보다 수신이 늦어지는 경우, 브라우저 렌더링이 늦어질 수 있는데, 이를 우선순위를 정함으로써 해결이 가능하다

> Server Push

• HTML 문서 상에서 필요한 리소스를 클라이언트 요청 없이 보낼 수 있다
• HTTP 1.1은 HTML 문서를 해석하기 위해 필요한 리소스를 재요청할 수 있는데, HTTP 2.0에서는 재요청 없이 Server Push 기법을 활용하여 해석이 가능하다

> Header Compression

• Header 정보를 HPACK 압축방식을 이용하여 압축 후 전송한다
• HTTP 1.1은 두 개의 요청 Header를 중복값이 존재해도 그냥 중복 전송을 진행하는 반면, HTTP 2.0에서는 Header에 중복값이 존재하는 경우 static/Dynamic Header Table 개념을 사용하여 중복 Header를 검출하고 중복된 Header는 index값만 전송하고 중복되지 않은 정보 값은 Huffman Encoding 기법으로 인코딩하여 전송한다

Connection 차이

 

HTTP 1.1 vs HTTP 2.0

 

🟠 HTTP 상태코드

- 상태코드는 3자리 숫자로 만들어져 있으며, 첫번째 자리는 1~5까지 제공된다

- 첫번째 자리가 4와 5인 경우는 정상적인 상황이 아니라는 것을 나타내기 때문에 사이트 관리자가 즉시 알아야 하는 정보이다

 

- 크게는 다음과 같이 정의할 수 있다

> 1xx (정보) : 요청을 받았으며 프로세스를 계속 진행함

> 2xx (성공) : 요청을 성공적으로 받았으며 인식했고 수용함

> 3xx (리다이렉션) : 요청 완료를 위해 추가 작업 조치가 필요함

> 4xx (클라이언트 오류) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없음

> 5xx (서버 오류) : 서버가 명백히 유효한 요청에 대해 충족을 실패함

 

1. 1XX : Information resonses

상태코드가 "1"로 시작하는 경우는 서버가 요청을 받았으며, 서버에 연결된 클라이언트는 작업을 계속 진행하라는 의미로, 해당 코드는 HTTP 1.0에서 지원되지 않는다

 

100 Continue

진행 중임을 나타내는 응답코드입니다. 현재까지의 진행상태에 문제가 없으며 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 되는 것을 알려준다

 

101 Switching Protocol 

클라이언트에 의해 보낸 업그레이드 요청 헤더에 대한 응답으로 보내지는 코드로, 클라이언트가 보낸 Upgrade 요청 헤더에 대한 응답에 들어가며 서버에서 프로토콜을 변경할 것임을 알려준다. 이는 Websocket 프로토콜 전환시에 사용된다

 

102 Processing (WebDAV)

서버가 요청을 수신하였으며 이를 처리하고 있지만, 아직 제대로 된 응답을 알려줄 수 없음을 알려준다

 

2. 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 코드와 함께 Range 헤더에 명시된 데이터의 부분(byte)부터 전송을 시작한다

 

207 Multi-Status

멀티-상태 응답은 여러 리소스가 여러 상태 코드인 상황이 적절한 경우에 해당되는 정보를 전달합니다.

해당 코드는 WebDAV(Web Distributed Authoring and Versioning)에 사용된다

 

208 ALREADY REPORTED

prostat (property + status) 응답 속성으로 동일 컬렉션으로 바인드된 복수의 내부 멤버를 반복적으로 열거하는 것을 피하기 위해 사용됩니다.

해당 코드는 DAV에 사용된다

 

226 IM Used (HTTP Delta encoding)

서버가 GET 요청에 대한 리소스의 의무를 다했고, 응답이 하나 또는 그 이상의 인스턴스 조작이 현재 인스턴스에 적용이 되었음을 알려줍니다.

 

3. 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 기술 사양에서 정의되었으며, 요청한 응답은 반드시 프록시를 통해서 접속해야 하는 것을 알려줍니다.

이는 프록시의 in-band 설정에 대한 보안상의 걱정으로 인하여 사라져가고 있다

 

306 unused

이는 더이상 사용되지 않으며, 현재는 추후 사용을 위해 예약되어 있습니다.

이는 HTTP 1.1 기술 사양 이전 버전에서 사용되었다

 

307 Temporary Redirect

클라이언트가 요청한 리소스가 다른 URI에 있으며, 이전 요청과 동일한 메소드를 사용하여 요청해야할 때 서버가 클라이언트에 이 응답을 직접 보냅니다.

이는 302 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 사용된 HTTP 메소드를 변경하지 말아야 하는 점만 다르다. 만약 첫 요청에 POST가 사용되었다면, 두번째 요청도 반드시 POST를 사용해야 한다

 

308 Permanent Redirect

현재 리소스가 HTTP 응답 헤더의 Location에 명시된 다른 URI에 위치하고 있음을 의미합니다.

이는 301 코드와 동일한 의미를 가지며, 사용자가 HTTP 메소드를 변경하지 말아야 한다는 것만 다르다. 만약 첫 요청에 POST가 사용되었다면, 두번째 요청도 반드시 POST를 사용해야 한다.

 

4. 4XX : Client error responses

 

400 Bad Request

이는 잘못된 문법으로 인해 서버가 요청을 이해할 수 없음을 의미합니다

 

401 Unauthorized

HTTP 표준에서는 "미승인(unauthorized)"를 명확히 하고 있지만, 의미상 이 응답은 "비인증(unauthenticated)"을 의미합니다.

클라이언트는 요청한 응답을 받기 위해서는 반드시 스스로를 인증해야 한다.

 

402 Payment Required

이는 나중에 사용될 것을 대비해 예약되었습니다.

첫 목표로는 디지털 결제 시스템에 사용하기 위해 만들어졌지만 지금은 사용되고 있지는 않다

 

403 Forbidden

클라이언트는 콘텐츠에 접근할 권리를 가지고 있지 않다. 예를 들어 사용자가 미승인이어서 서버는 거절을 위한 적절한 응답을 보낸다. 401 코드와 다른 점은 서버가 클라이언트가 누군지 알고 있다

 

404 Not Found

서버는 요청받은 리소스를 찾을 수 없습니다.

브라우저에서는 알려지지 않은 URL을 의미한다. 이는 API에서 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수도 있다. 서버들은 인증받지 않은 클라이언트로부터 리소스를 숨기기 위해 이를 403 코드 대신에 전송할 수도 있다.

 

405 Method Not Allowed

요청한 메소드는 서버에서 알고 있지만, 제거되었고 사용될 수 없습니다.

어떤 API에서 리소스를 삭제하는 것을 금지할 수 있는데 그 예시로 필수적인 메소드인 GET과 HEAD는 제거될 수 없으며 이 에러 코드를 리턴할 수 없다.

 

406 Not Acceptable

이 응답은 서버가 서버 주도 콘텐츠 협상을 수행한 후, 사용자 에이전트에서 정해준 규격에 따른 어떠한 콘텐츠도 찾지 않았을때 웹서버가 보냅니다.

 

407 Proxy Authentication Required

이 코드는 401 코드와 비슷하지만 프록시에 의해 완료된 인증이 필요합니다.

 

408 Request Timeout

이는 요청을 한지 시간이 오래된 연결에 일부 서버가 전송하며, 어떨 때에는 이전에 클라이언트로부터 어떠한 요청이 없었다고 하더라도 보내지기도 합니다.

이는 서버가 사용되지 않는 연결을 끊고 싶어한다는 것을 의미하며, 이는 특정 브라우저에서 빈번하게 보인다. Chrome, Firefox 27+, IE9 등과 같이 웹서핑 속도를 올리기 위해 HTTP 사전 연결 메카니즘을 사용하는 브라우저들이 해당된다. 이외의 일부 서버는 이 메시지를 보내지 않고 연결을 끊어버리기도 한다

 

409 Conflict

이는 요청ㅇ이 현재 서버의 상태와 충돌될 때 보냅니다.

 

410 Gone

이는 요청한 콘텐츠가 서버에서 영구적으로 삭제되었으며, 전달할 수 있는 주소 또한 존재하지 않을 때 보냅니다.

클라이언트가 그들의 캐시와 리소스에 대한 링크를 지우기를 기대한다. HTTP 기술 사양은 이 상태 코드가 '일시적인, 홍보용 서비스'에 사용되기를 기대한다. API는 알려진 리소스가 이 상태코드와 함께 삭제되었다고 강요해서는 안된다.

 

411 Length Required

서버에서 필요로 하는 Content-Length 헤더 필드가 정의되지 않은 요청이 들어왔기 때문에 서버가 요청을 거절합니다.

 

412 Precondition Failed

클라이언트의 헤더에 있는 전제 조건은 서버의 전제 조건에 적절하지 않습니다.

 

413 Payload Too Large

요청 엔티티는 서버에서 정의한 한계보다 큽니다.

서버는 연결을 끊거나 혹은 Retry-After 헤더 필드로 돌려 보낼 것이다

 

414 URI Too Long

클라이언트가 요청한 URI는 서버에서 처리하지 않기로 한 길이보다 깁니다.

 

415 Unsupported Media Type

요청한 미디어 포맷은 서버에서 지원하지 않습니다.

따라서 서버는 해당 요청을 거절할 것이다.

 

416 Requested Range Not Satisfiable

Range 헤더 필드에 요청한 지정 범위를 만족시킬 수 없습니다.

범위가 타겟 URI 데이터의 크기를 벗어났을 가능성이 있다.

 

417 Expectation Failed

Expect 요청 헤더 필드 요청한 예상이 서버에서는 적당하지 않음을 알려줍니다.

 

418 I'm a teapot

서버는 커피를 찻 주전자에 끓이는 것을 거절합니다.

https://datatracker.ietf.org/doc/html/rfc2324 에서 사용되는 코드이다

만우절을 맞이해서 농담식으로 만든 코드라나 뭐라나..🙄

So cute,,,

421 Misdirected Requset

서버로 유도된 요청은 응답을 생성할 수 없습니다.

이는 서버에서 요청 URI와 연결된 스킴(Scheme)과 권한을 구성하여 응답을 생성할 수 없을때 보내진다

 

422 Unprocessable Entity (WebDAV)

요청은 잘 만들어졌지만, 문법 오류로 인하여 따를 수 없습니다.

 

423 Locked (WebDAV)

리소스는 접근하는 것이 잠겨있습니다.

 

424 Failed Dependency (WebDAV)

이전 요청이 실패하였기 때문에 지금의 요청도 실패하였습니다.

 

426 Upgrade Required

서버는 지금의 프로토콜을 사용하여 요청을 처리하는 것을 거절하였지만, 클라이언트가 다른 프로토콜로 업그레이드를 하면 처리할지도 모릅니다.

서버는 Upgrade 헤더와 필요로 하는 프로토콜을 알려주기 위해 426 응답을 보낸다.

 

428 Precondition Required

오리진 서버는 요청이 조건적이어야 합니다.

클라이언트가 리소스를 GET해서 수정하고 PUT으로 서버에 돌려놓는 동안 서드파티가 서버의 상태를 수정하여 발생하는 충돌인 'Lost Update'을 예방하기 위한 목적이다.

 

429 Too Many Requests

사용자가 지정된 시간에 너무 많은 요청을 보냈습니다; "rate limiting"

 

431 Requests Header Fields Too Large

요청한 헤더 필드가 너무 크기 때문에 서버는 요청을 처리하지 않을 것입니다.

요청은 크기를 줄인 다음에 다시 전송해야 합니다.

 

451 Unavailable For Legal Reasons

사용자가 요청한 것은 정부에 의해 검열된 웹 페이지와 같은 불법적인 리소스입니다.

 

 

5. 5XX : Server error responses

500 Internal Server Error

웹 사이트 서버에 문제가 있음을 의미하지만, 서버는 정확한 문제에 대해 더 구체적으로 설명이 불가능합니다.

 

501 Not Implemented

서버가 요청을 이행하는데 필요한 기능을 지원하지 않음을 나타냅니다.

 

502 Bad Gateway

서버가 게이트웨이로부터 잘못된 응답을 수신했음을 의미합니다.

인터넷 상의 서버가 다른 서버로부터 유효하지 않은 응답을 받은 경우 발생한다.

 

503 Service Unavailable

서버가 요청을 처리할 준비가 되지 않았습니다.

일반적인 원인은 유지보수를 위해 작동이 중단되거나 과부하가 걸린 서버이다. 이 응답과 함께 문제를 설명하는 사용자 친화적인 페이지가 전송되어야 하는 것에 유의해야 한다. 이 응답은 임시 조건에 사용되어야 하며, Retry-After : HTTP 헤더는 가능하면 서비스를 복구하기 전 예상 시간을 포함해야 한다. 웹마스터는 또한 이러한 일시적인 조건 응답을 캐시하지 않아야 하기에 이 응답과 함께 전송되는 캐싱 관련 헤더도 주의해야 한다.

 

504 Gateway Timeout

웹 페이지를 로드하거나 브라우저에서 다른 요청을 채우려는 동안 한 서버가 액세스하고 있는 다른 서버에서 적시에 응답을 받지 못했음을 의미합니다.

이 응답은 서버가 게이트웨이 역할을 하고 있으며 적시에 응답을 받을 수 없을 때 주어집니다. 이 응답은 대개 인터넷 상 서버 간의 네트워크 오류이거나 실제 서버의 문제이다. 컴퓨터나 장치, 인터넷 연결 문제가 아닐 수 있다.

 

505 HTTP Version Not Supported

서버에서 지원되지 않는 HTTP 버전을 클라이언트가 요청하였습니다.

대부분의 웹 서버가 1.x 버전의 HTTP 프로토콜을 지원한다고 가정한다. 실제로 1.0 이하의 매우 오래된 버전은 최신 버전의 프로토콜보다 보안 및 성능이 좋지 않기 때문에 요즘 거의 사용되지 않는다. 따라서 웹 브라우저에서 이 오류가 표시되는 경우 웹 서버 소프트웨어에서 지원하는 HTTP 버전을 확인해 봐야 한다.

 

506 Variant Also Negotiates

서버에 내부 구성 오류가 있는 경우 발생합니다.

요청을 위한 투명한 컨텐츠 협상이 순호나 참조로 이어진다.

 

507 Insufficient Storage

선택한 가변 리소스는 투명한 서버에 내부 구성 오류가 있는 경우 발생합니다.

콘텐츠 협상에 참여하도록 구성되므로 협상 과정에서 적절한 끝점이 아니다.

 

508 Loop Detected (WebDAV)

서버가 요청을 처리하는 동안 무한 루프를 감지한 경우 발생합니다.

 

510 Not Extended

서버가 요청을 이행하려면 요청에 대한 추가 확장이 필요합니다.

 

511 Network Authentication Required

클라이언트가 네트워크 액세스를 얻기 위해 인증할 필요가 있음을 나타냅니다.

 

 

---

이후 HTTP 개념 스터디는 다음 글에서 계속 이어서 해보도록 하자!!