[Network] 웹과 HTTP

HTTP

HTTP(HyperText Transfer Protocol)은 텍스트 기반의 통신 규약으로, 인터넷에서 데이터를 주고받을 수 있는 프로토콜이다. HTTP는 클라이언트-서버 구조로 이루어져 request-response의 과정을 통해서 동작한다.

Clint : Server에 request
Server : Client에 response

 

데이터 통신에 TCP나 UDP와 같은 하위 프로토콜을 직접 사용하는 경우는 많지 않으며, 대부분 HTTP를 이용한다. HTTP는 TCP/IP를 이용하는 응용 프로토콜이며, 무상태(stateless), 비연결형(connectionless)이라는 특징을 가진다.

 

- stateless하다는 것은 서버가 클라이언트의 이전 상태와 정보를 보존/저장하지 않는다는 의미이며(저장이 필요할때는 쿠키와 세션을 이용한다), 서버 입장에서는 동일한 클라이언트의 요청이라도 각각의 요청을 독립적으로 받아들인다. 이는 서버의 scale-out에도 유리하다.

 물론 로그인 상태를 브라우저 쿠키나 서버 세션들을 사용해서 유지하기 위한 상황과 같은 몇몇 상황에서는 무상태성을 유지할 수 없다. 하지만 요즘은 jwt 토큰방식의 stateless한 로그인을 사용하는 등 상태 유지를 최소한으로 하려고 노력하고 있다.

 

- connectionless라는 것은 서버와의 request-response가 종료되면 바로 TCP/IP 연결이 종료된다는 것이다. 이를 통해 불필요한 연결의 유지를 최소화하여 서버 리소스를 효율적으로 관리할 수 있게 된다. 

다만 비연결성을 위해서는 새로운 통신을 위해서는 새로운 연결이 필요하기 때문에, 통신시마다 3 way handshake를 비롯한 연결과정이 필요하다. 따라서 HTTP2에 와서는 지속 연결(persistent connection)을 사용하여 페이지 단위로 연결을 유지하거나, HTTP3는 UDP를 사용하면서 연결 작업도 최소화하게 된다.

 

 

 

 

 

HTTP Persistence

 초기의 HTTP연결은 영속적이지 않았다(Nonpersistent HTTP). 초기 HTTP(HTTP 1.0)는 요청마다 새로운 TCP연결이 이루어져야 했다. 이 말은 즉, 1개의 TCP 연결로는 1개의 object만 전송이 가능했다. 따라서 웹 페이지의 오브젝트가 복잡해질수록, 서버 사이에는 여러번에 TCP연결이 이루어져야 했다. TCP연결을 열고 닫는 과정도 리소스를 소비하기 때문에 이러한 단순한 모델은 성능상의 제약을 발생시킬수밖에 없다.

 

non-persistence in HTTP 1.0

 

 그래서 HTTP 1.1에서 연속적인 요청 사이에 연결을 유지하는 Persistence connection model과 응답조차 기다리지 않고 연속적인 요청을 보내는 Pipelining Model (컴퓨터구조에서 배웠던 그것과 유사하다. 성능 개선을 위해서 특정 사이즈만큼의 패킷을 한번에 보내는 방법. GBN이나 Selected Repeat이 있다. 참고: https://eckrin.tistory.com/63)이 새로 보급되었다. 

 

non-persistence vs persistence

 

non-pipelined vs pipelined

 

Nonpersistence : 2*RTT per obj + Connection time(3-way Handshaking)

Persistence : 2*RTT per obj

Pipelining : shorter than above

 

 

RTT(Round Trip Time)

RTT는 패킷망 위에서 패킷을 목적지에 보낼 때 패킷이 목적지에 도달하고 나서 응답이 다시 출발지로 돌아오기까지의 시간을 이야기한다. 

 

HTTP 응답코드

1xx (Informational)

요청이 처리중임을 나타내는데, 많이 사용되지는 않는다.

 

2xx (Successful)

클라이언트 요청이 성공적으로 처리되었음을 나타낸다.

- 200 OK

- 201 Created (새로운 리소스가 생성됨)

- 202 Accepted (배치 작업과 같이 현재 처리되지는 않음)

- 204 No Content (response에 보낼 데이터가 없음)

 

3xx (Redirection)

리다이렉션 필요 (클라이언트에게 추가적인 요청 요구)

- 301 Moved Permanently (해당 리소스가 영구적으로 다른 URI로 이동됨 - 요청 body 없이 GET메서드로 재요청할 수 있음)

- 303 See Other (요청에 대한 결과를 새로운 URI에서 얻을 수 있음 - 주문 결과를 뿌려줄 때 많이 사용, 중복 POST요청 방지)

- 307 Temporary Redirect (임시로 다른 URI로 요청해야 함)

- 308 Permenant Redirect (301과 유사하지만, 처음 요청에 대한 메서드와 body를 유지해야 함)

 

4xx (Client Error)

클라이언트 요청에 오류가 있음을 나타낸다.

- 400 Bad Request (요청 파라미터, json body와 같은 구문 오류)

- 401 Unauthorized (리소스에 대한 액세스 권한(인증) 필요 - 이름이 Unauthorized지만 인증에 관련된 오류임)

- 403 Forbidden (액세스 권한 필요 이외의 사유로 리소스 접근(인가)이 금지됨)

- 404 Not Found (요청한 리소스를 사용할 수 없음)

 

5xx (Server Error)

서버에 오류가 있음을 나타낸다.

- 500 Internal Server Error (서버에 오류가 있음)

- 501 Not Implemented (요청한 URI 메서드를 서버가 지원하지 않음)

- 502 Bad Gateway (프록시 서버나 게이트웨이 역할을 하는 서버가 그 뒷단의 서버로부터 잘못된 응답을 받음)

- 503 Service Unavailable (서버가 일시적인 과부하, 점검, 작업 등으로 인해 잠시 요청을 처리할 수 없음)

 

 

 

 

 

HTTP 역사

HTTP 1.0

ㆍMETHOD : GET, HEAD, POST

ㆍNon persistence -> RTT 증가

 

HTTP 1.1

ㆍMETHOD : GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS

ㆍPersistence. 서버는 모든 데이터가 클라이언트로 전송되면 더 이상 보낼 데이터가 없음을 알리고 연결 종료 (keep-alive 옵션으로 연결 유지)

ㆍ오늘날 가장 많이 사용

ㆍ압축, 가상호스팅, 캐시 등이 추가되어 응답속도 향상, 대역폭 절약

ㆍHOL blocking 문제 (한 요청이 완료될때까지 다음 요청 대기 필요)

 

HTTP 2.0

ㆍHTTP 1.1 프토토콜 계승, 성능 향상에 초점 (헤더 압축, 멀티플렉싱)

ㆍ멀티플렉싱 (여러개의 스트림을 사용하여 송수신)을 통해 HOL blocking문제 해결

ㆍHTTPS 기반 동작 (응용계층과 전송계층 사이에 SSL/TLS 신뢰계층 존재) - 보안 세션을 생성하여 상태정보 공유

 

HTTP 3.0

ㆍ연결에 UDP 사용
ㆍTLS/SSL 계층을 QUIC계층이 감싸고 있는 구조로, UDP를 사용함에도 낮은 패킷 손실률 유지

 

현재 가장 많이 사용되는 스펙은 HTTP/1.1이며, HTTP/2, 3의 경우는 성능 향상을 위한 부분에 초점이 맞추어져 있다.

 

 

HTTP Method (GET, POST, PUT, PATCH, DELETE)

HTTP 통신을 위해서 RESTful한 API의 사용이 권장된다. RESTful API란 REST한 특징을 갖는 api를 말하는데

1. Stateless - 요청의 처리에 필요한 모든 정보를 포함. 이전 요청과 독립적인 관계를 가진다.
2. URI를 통해 자원을 명시하고, Method를 통해서 자원에 대한 행위(CRUD)을 적용한다.

 

라는 두 가지 특징을 만족하는 api 스펙을 말한다. 여기서 자원에 대한 행위를 명시하기 위해서 많이 사용되는 것이 HTTP Method이다.

 

(완벽히 REST방식으로 api를 설계하기 위해서는 여러 한계가 존재하기에 메서드가 아닌, uri에 행위를 명시하기도 하는데 이것을 '컨트롤 uri'라고 많이 부른다.)

 

1. GET

• GET방식이란 데이터를 읽기 위해서 사용되는 메소드를 의미한다.
• 같은 요청을 여려 번 하더라도 동일한 response가 오기 때문에 중복 전송 처리를 별도로 할 필요가 없다.
• 일반적으로 request header만 존재하며, body로 데이터를 담아 보내지 않는다.
• 데이터를 서버에 전달할 필요가 있다면 query parameter나 path value 형태로 전달하는 것이 좋다.

 

2. POST, PUT, PATCH, DELETE

• 데이터를 변경하기 위해서 사용하는 request 방식이다.
• POST는 데이터 등록, PUT은 update(완전 대체, 없다면 생성), PATCH는 일부 update(일부 대체), DELETE는 데이터 삭제에 주로 사용된다.
• request body에 내용을 담아서 보냄.
• POST는 다른 메서드와 다르게 여러번 호출하면 같은 동작이 중복해서 발생할 수 있다. (GET: 같은 조회, PUT: 대체, DELETE: 동일 삭제요청) -> 따라서 재요청에 신중해야 함.

+ form태그(x-www-form-urlencoded, key-value형태)를 이용하면 GET, POST요청만 가능하다. 따라서 통일성을 위해서 주로 js로 ajax요청을 하고, 데이터는 json을 이용한다.