책을 읽어보자/그림으로 배우는 HTTP & Network Basic

[우테코 권장도서] 그림으로 배우는 HTTP 어쩌구저쩌구 2장

강한 맷돼지 2023. 8. 6. 16:58

2장 간단한 프로토콜 HTTP

이번장은 좀 가볍게 넘어가도 괜찮을것 같다. 별내용이없다. 신기하긴한데 쓸모없는것들? 이거쓸까? 이런것들만 있다.

2.1 HTTP는 클라이언트 서버간의 통신을한다.

HTTP는 서버랑 클라이언트가 분명존재하고 각각의 책임은 확실하다는것이다.

또한 요청없이 서버는 응답할수 없다는건데 그래서 서버가 먼저 반응해서 클라가 움직여야할때는 FCM(HTTP/2 기반이라한다)을 이용하던 소켓통신을 하던 다른 방법을 찾는것이라는걸 한번더 알 수 있게 해준다.

2.2 리퀘스트와 리스폰스를 교환하여 성립

당연한 이야기를 하며 OKHTTP에서 쫙 보여주는 HTTP 통신 내역들을 보여준다. 이에대해 좀더 원초적으로 필요할때 한번더 살펴보면 좋을것 같기도 하지만 여기에는 자세한 내용은 안나온다.

HTTP로 서버통신을 해봤다면 알만한 내용들이다.

2.3 HTTP는 상태를 유지하지 않는 프로토콜

HTTP는 스테이트리스 프로토콜이라고 한다.즉 이전에 어떤 상태로 통신했던 매번 똑같은것이다.

즉 한번 인증했어도 뭐 알바임? 하고 헤더를 붙여서 보내라고 요구하든 아님 쿠키를 통해서 인증을 확인하는등의 과저이 이뤄진다.

이를 통해 데이터를 빠르고 확실하게 처리할수 있는 범위성을 얻을수 있다는데 결론적으로 함수형프로그래밍 처럼 무조건 같은 결과를 볼 수 있고 처리도 간단하여 처리하는 입장에서 명확해진다는것 같다. 또한 서버쪽에서는 한두개의 클라이언트가 접속하는게 아닐텐데 이를 모두 상태저장한다면 아마 서버가 굉장히 힘들어 할텐데 이를 확실히 줄일 수 있다고 이장 후반에 나와있다.또한 지속 연결 혹은 파이프 라인 또한 이에 대한 보완책이다.

2.4 리퀘스트 URI로 리소스를 식별

당연한 소리를 자꾸한다. 그냥 궁금하면 보자 별내용없다.

2.5 서버에 임무를 부여하는 HTTP 메소드

서버통신을 하다보면 아주 맨날 보는 메서드들 근데 사실상 잘 안쓰여서 이딴게 있었어 싶은 메서드들도 소개된다.

간단하게 한줄설명과 함께 살펴보고 넘어가보겠다

GET: 리소스 획득

URI에 있는 리소스 내놔이다. 서버에서 그 URI에 있는 내용을 해석해서 내뱉는다고 한다.

만약 거기 텍스트가 있다면 그대로 주고 그안에 프로그램이있다면 실행후 출력해서 내용을 돌려준다고 한다.(이건 서버 개발자가 어떻게 짜냐일것 같다.)

POST: 엔티티 전송

메소드 전송하기위해 사용 서버에 정보 보내려고 사용하는것이 주이다. 서버에다가 정보 집어넣는 상황에 매일 보지 않았는가?

PATCH : 이책에 안나오는데 부분적으로 고치기

아니 이책 2007년에 등록된거 보니 아주 구닥다리이다. PATCH는 실제로 종종 쓰이는데 이책에 없다.

HTTP PATCH 메서드는 HTTP 1.1의 일부로서, "RFC 5789"에서 2010년에 정의되었습니다. 이 메서드는 리소스의 부분적인 수정을 허용하므로, 전체 리소스를 업데이트하지 않고도 리소스의 일부분만을 변경할 수 있게 해줍니다.

이런것이니 알고있어야한다.

PUT : 파일 전송

파일을 전송하기 위해서 사용하게되는데 FTP에 의해 파일 업로드 처럼 리퀘스트에 담는것을 URI에 담아라 이런뜻이다.

사실상 안드 개발자 입장에서는 PUT이나 POST나 뭐 거기서 거기 아님? 이럴수 있지만 분명 용처가 있어서 api를 살펴보면 다 구분되어있다.

HTTP/1.1에는 자체 인증이 없어 보안상에 문제가있어 일반적인 웹사이트에는 사용되지않는다고 나오지만 우리는 안드개발자라 인증을 하고 사용해서 쓰는경우가 가끔있었던것 같다.

HEAD: 메시지 헤더 취득

이제부터 슬슬 생소한거 나온다 이딴거 쓸일이 있을까 싶은데 GET메서드와 같은 기능이지만 메시지 바디를 돌려주지 않는다고 한다.

URI 유효성과 리소스 갱신시간을 확인하는 목적으로 쓰인다는데.

아주 언젠간 쓰일수도 있지않을까?

DELETE: 파일삭제

말그대로다 이건 가끔 쓰이는데 PUT의 반대나 다름없다.

여기서도 HTTP/1.1에는 인증기능 없어서 보안문제가 있어서 웹에서는 안쓰이지만 우리는 인증받는 안드다 쓰라면쓰자.

OPTIONS: 제공하고 있는 메서드 문의

이런거 과연쓸까? 리퀘스트URI가 제공하는 메서드를 조사하기 위해서 쓰인단다 요청넣으면 GET,POST,HEAD 등 쓸수있는 메서드가 온다는데

서버개발자한테 물어보던 공공 api면 문서를 보는게 확실한거 아닌가 싶다. 뭔가 메서드가 해커마냥 음침하다.

TRACE: 경로조사

이거 루프백 어쩌구 저쩌구 나오는데 거의 사용되지않고 보안상의 문제가있어 잘 사용안된단다.내용도 이게 뭔가 싶다.

CONNECT: 프록시에 터널링 요구

이것도 뭔가 싶다 TCP 통신을 위해서 터널링 시키기위해서 사용한다는데 주로 SSL,TSL등의 프로토콜 암호화 된것을 터널링 시키기 위해 사용한다는데

언젠가 이해도가 높아지면 쓸일도 오지않을까? 하지만 철저한 실용주의 지금 나에게는 1도필요없기에 있다는것만 알고 넘어간다.

2.6 메소드를 사용해서 지시를 내리다.

상황적절하게 메소드를 이용하라는것이다 그리고 대소문자 구분해야 하므로 대문자로 무조건 쓰란다.

2.7 지속 연결로 접속량을 절약

이부분 OKHTTP 까보면 커넥션풀과 커넥션을 재활용하는 부분이 나오는데 이것인것 같다. 역시 네트워크부터 공부하길 잘했다 재미있다.

OKHTTP는 커넥션풀을 관리하고 이것을 이용해서 커넥션을 재활용한다.-> 디폴트로 커넥션을 5개를 유지 유휴시간이 5분이다.

즉 여기서 나오는이야기가 실제적으로 Okhttp에 적용되어있다. 막 Okhttp,Retrofit 코드를 까보다보면 connection pool을 뒤져서 커넥션이 있다면 재활용하는 코드들이 나온다. 앞으로 나오는 이야기들을 효율적으로 이용하기 위한 행위였던것이다.

https://hbase.tistory.com/86 참고하면 좋을것같다.

이제 책 내용을 봐보자.

HTTP 초기 버전에서는 HTTP 통신을 할때마다 TCP에 의해 연결과 종료를 했다고한다.

초기 버전에서는 오가는 데이터가 조그마한 텍스트 정도라 상관없었지만 요즘을 기준으로 보면 이미지가 포함된 HTML문거 같은것만 보내도 문서 받아오는데 한번 그후 안에있는 이미지 받아온다고 또 여러번 커넥션을 연결하고 끊어버리는 일이 일어나 비효율적이며 통신량이 증가한다고 한다.

이를 해결하기위해 지속연결과 파이프라인을 적용한다고 한다.

2.7.1 지속연결

이런 문제를 해결하기위해 지속연결을 하는데 어느 한쪽(클라이언트,서버)가 명시적으로 연결을 종료하지 않는 이상 TCP연결을 유지한다고 한다.

그래서 Okhttp의 커넥션이 유휴시간을 지정할 수 있는것이였다.

그래서 연결해놓고 한번에 쭈루룩 보내고 받고 할수있게 되어 효율적이 된것이다.

이해가 안된다면 책의 이미지를 한번보면 한방에 이해된다.

어쩃든 이말을 멋있게 한번에 정리하면

TCP커넥션의 연결과 종료를 반복하는 오버헤드를 줄여주기 떄문에 서버에 대한 부하가 경감된다.또한 오버헤드가 줄어든 만큼 웹페이지도 빠르게 로딩된다.

이는 HTTP/1.1에는 표준이고 1.0에서는 정식사양이 아니라한다.

2,7.2 파이프 라인화

지속연결을 통해 연결은 해놨는데 이전에는 리퀘스트 하나보내고 리스폰스 받고 뭔일을 하는 동기처리 같은 느낌이였는데 이제는

리스폰스가 오기전에 따다다 요청부터 보낼수있는 비동기스러운 방법을 파이프라인화라한다.

그래서 이것을 적용하면 속도가 늘어난다고 한다. 특히 굉장히 많은 요청일수록 속도가 늘어난다고 한다.

2.8 쿠키를 사용한 상태 관리

HTTP는 스테이스 리스 프로토콜이라 기억을 아예 못한다.

그니까 한번 인증해도 다음번에도 또 요구하고 그래서 매번 헤더에 인증정보 붙여서 보내고 어쩌구 저쩌구 짜증나는 행위를 하는것이다.

근데 이것을 보완하기 위해서 쿠키가 나왔다고 하는데

웹에서는 쿠키가 당연시되는 이야기같은데 안드로이드를 하면서는 쿠키를 쓰는것을 못봤는데 이유를 모르겠어서 한번 나중에 찾아봐야할것같다.

현재 대충 구글링 해보니 안드로이드에서도 Okhttp에서 지원하는 cookieJar라 인터페이스도 있다고 하니 나중에 인증같은것들을 이것을 통해 하여 편히하다면 충분히 이용해볼만한 가치가 있을것같다.

그래서 쿠키가 뭔지 보면 쿠키는 리쿼스트와 리스폰스 에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하는것이라한다.

쿠키는 리스폰스로 온 Set-Cookie라는 헤더 필드에 쿠키를 클라이언트에 보존하고 서버로 다시 리퀘스트를 보낼때 이 쿠키를 붙여서 보내면 쿠키를 서버가 확인해서 기존 접속 내용들을 뒤져볼수 있는것이다.

근데 사실 현재 인증 인가 방식이랑 거기서 거기 아닌가 라는 생각이 들긴한다. 추후 한번 더 깊게 알아보면 좋을것 같다.