http 메시지에 모든 것을 전송한다.
기반 프로토콜을 봐보면
왜 TCP가 안정적인데 UDP를 썼을까?
그 이유는 TCP는 3 way handshaking도 해야하고 데이터도 많아서 속도가 빠르지 않기 때문!
HTTP/3는 UDP에 성능을 개선
이렇게 클라이언트 서버 구조를 분리하면
클라이언트는 UI나 사용성(다양한 접근 방식 PC, 안드로이드 등)에 집중할 수 있고, 서버는 대용량으로 요청이 들어왔을 때 어떻게 대처할 것인지만 집중하면 된다.
즉 stateless는 한 번 요청할 때 모든 정보를 포함해서 보내고 서버는 상태를 유지하지 않는다.
만약 기존에 연결했던 서버1이 연결이 끊기더라도 어차피 요청을 보낼 때 모든 정보를 포함해서 보내기 때문에 어떤 서버에서 요청을 받던지 상관이 없다. 그러므로 Scale out을 하는데 유리하다. scale out은 일단은 단순하게 요청받는 서버의 개수를 늘린다고 생각하면 된다.
단점은 로그인 같은 상태를 유지하는 경우가 있다. 이를 개선하기 위해서 쿠키와 서버의 세션을 이용한다.
그리고 데이터를 너무 많이 보낸다.
TCP/IP는 요청과 응답을 할 때 연결이 유지된다. 그러나 연결을 유지하지 않는 모델은
이렇게 요청하고 응답한 후에
바로 연결을 꾸며버린다. 이러므로 자원 소모를 줄일 수 있다.
한계가 명확한데,
지금은 이를 개선하기 위해서
지금은 HTTP 지속 연결(Persistent Connections)로 해결 했다.
HTTP 메시지의 구조를 보면
시작 라인은 크게 Request-line과 Status-line이 있는데
- 요청 메시지는 Request-line이다. 즉 요청 보낼 때의 http 메시지이다.
Request-line의 구조를 보면
method는 종류로 GET, POST, PUT, DELETE 등이 있고 서버가 수행해야할 동작을 지정한다.
그리고 Request target은 요청 대상으로 absolute-path[?query]로 되어 있다.
HTTP-version은 말 그대로 HTTP 버전을 나타낸다.
- 응답 메시지는 Status-line인데, 클라이언트가 응답을 받을 때의 메시지이다.
status-line의 구조를 보면
status-code는 요청 성공, 실패를 나타내고,
reason-phrase는 사람이 이해할 수 있는 짧은 상태 코드 설명글을 말한다.
대소문자 구분이 없고 띄어쓰기가 가능하다(하지만 :은 붙여 써야한다. 예로 Content-Type: )
HTTP 헤더의 용도를 보면
표준 헤더가 너무 많고, 필요시 임의의 헤더를 추가 가능하다.
실제 전송할 데이터로 HTML문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터 전송이 가능하다.
[ http ] 06. HTTP 상태코드 (0) | 2021.11.25 |
---|---|
[ http ] 05. HTTP 메서드 활용 (0) | 2021.11.10 |
[ http ] 04. HTTP 메서드 (0) | 2021.11.01 |
[ http ] 02. URI와 웹 브라우저 요청 흐름 (0) | 2021.09.17 |
[ http ] 01. 인터넷 네트워크 (0) | 2021.09.17 |