[HTTP][심화]HTTP메서드

비연결성

-클라이언트가 요청할 때에만 응답을 주고 서버는 연결을 끊는다.

-HTTP는 기본이 연결을 유지하지 않는 모델

-인반적으로 초단위 이하의 빠른 속도로 응답

-1시간동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개가 되므로 매우 적음

-서버자원을 매우 효율적으로 사용할 수 있음

 

단점

-TCP/IP 연결을 새로 맺어야 함 -3way handshake 시간 추가

-웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지등 수 많은 자원이 함께 다운로드

-지금은 HTTP 지속연결(Persistent Connections)로 문제 해결

-HTTP/2,HTTP/3에서 더 많은 최적화

 

HTTP 초기에는 요청에 대해 하나하나 연결하고 응답후 종료를하며 연결,종료를 낭비했지만 HTTP지속 연결로 바뀌면서 요청들을 연결할때 한번에 응답을 주고 응답이 다 끝나면 종료를 하는 식으로 변경이 됐음. 그마저도 h2,h3으로 변경되면서 응답속도를 확연하게 줄여줌

h3는 udp프로토콜을 쓰면서 연결속도 자체도 확연히 줄어듦

 

스테이스리스 -서버개발자들이 어려워하는 업무

선착순 이벤트를 할경우 같은시간에 맞추어 발생하는 대용량 트래픽을 감당하기 어려움 최대한 stateless하게 설계해서 대용량 트래픽이 올때 서버를 확 늘려서 감당할 수 있게만들면됨

 

 

HTTP메서드의 속성

안전

-호출해도 리소스를 변경하지 않는다.(해당 리소스만 고려)

Head는 Get과 같지만 body부분만 뺀것

멱등(Idempotent)

-한번 호출하든 두번호출하든 100번 호출하든 결과가 똑같다

-멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지 고려하지 않는다.

-멱등 메서드

   get : 한번이든 100번이든 같은 결과가 조회된다.

   put : 결과를 대체한다 따라서 같은 요청을 여러번해도 최종 결과는 같다

   delete : 결과를 삭제한다 같은 요청을 여러번 해도 삭제된 결과는 똑같다

   post : 멱등이 아니다 두번호출하면 같은 결제가 중복해서 발생할 수 있다.

멱등의 활용

-자동 복구 메커니즘

-서버가 Timeout 등으로 정상 응답을 못주었을 때 , 클라이언트가 같은 요청을 다시 해되 되는가 ? 판단근거

캐시가능(Cacheable)

-응답 결과 리소스를 캐시해서 사용해도 되는가?

-get ,head, post, patch 캐시가능

-실제로는 get, head정도만 캐시로 사용

   post, patch는 본문 내용까지 캐시키로 고려해야하는데, 구현이 쉽지않음