[3장 ~ 4장] 3.4 ~ 4.7

책을 읽고 공부한 내용을 기록한 글입니다.

상태코드

HTTP 상태코드는 응답메시지에 붙어 나오는 것으로 100,200,300,400,500 이렇게 크게 다섯 가지로 나뉜다.

• 100번대: 정보성 상태코드
  • 정보성 상태코드이고 HTTP/1.1에 도입되었다. (이전 버전에서 인식하지 못한다.)
  • 그 중 100 은 Continue를 의미하며 클라이언트가 서버에 entity 본문을 보내기 전에 서버가 해당 본문을 받아 들일건지 확인하기 위한 플래그 같은 용도다.
  • 클라이언트는 100-continue Expect헤더를 담아 보내고, 응답을 기다릴 수 있지만 무한정 기다릴 수 는 없으니 타임아웃 시 그냥 본문을 보내야한다. 
  • 서버는 100-continue Expect를 요청한 클라이언트에게만 100을 보내야되고 그게 아니라면 보내면 안된다.
  • 만약 100-continue Expect 요청을 받고, 서버가 본문을 읽기전에 요청이 끊어졌을 경우 서버에서 일방적으로 응답을 보내고 커넥션을 닫으면 안된다. 클라이언트가 무한대기하는 경우가 발생하기 때문이다

---

• 200번대: 성공 상태 코드
  • 200: OK
  • 201: Created (PUT과 같은 요청의 응답으로)
  • 202: Accepted (요청을 받아들였지만 서버가 수행했는지는 알 수 없음)
  • 203: 리소스에 대한 검증이 안됐을 경우
  • 204: No Content - Entity 본문이 없는 응답으로 새로고침 용도로 사용한다.
  • 205: Reset Content 브라우저에게 현재 Html form에 있는 모든 값을 리셋하라고 지시
  • 206: 부분/범위 요청이 성공했을 경우

---

• 300번대: 리다이렉션 상태코드
  리소스에 대한 변화가 생길 경우 알려주기 위한 상태코드, 관심사가 변경된 리소스에 대한 응답도 담당하지만 무결성 검사용도로도 사용할 수 있다. 
  
  • 300: Mutiple Choices -> 여러 리소스를 가리키는 요청이 들어올 경우 리소스 목록과 함께 반환.
  • 301: 요청한 URL이 영구적으로 옮겨졌을때. 응답은 location 헤더에 현재 리소스가 존재 중인 URL을 포함해야된다. 
  • 302: 301이랑 비슷지만 임시로 사용해야되고, 이후 요청에서는 원래 URL을 이용해 접근해야된다.
  • 303(HTTP/1.1부터 302대신 사용): 리소스를 다른 URL에서 가져와야할 때 응답. -> POST 요청에 대한 응답으로 적절하다
  • 304: Not Modified 로 요청한 리소스에 대한 수정이 없을 때 반환한다.
  • 305: Use Proxy - 리소스가 반드시 프락시를 거쳐 접근되야함을 의미
  • 307 (HTTP/1.1부터 302대신 사용) : Temporary Redirect == 302

---

• 400번대: 클라이언트 에러 상태코드
  • 400: Bad Request 잘못된 요청
  • 401: Unauthorized 권한이 없는 리소스에 대한 요청 - 인증정보가 필요함
  • 403: Forbidden 서버가 거절한 요청
  • 404: Not found 서버에서 리소스를 찾을 수 없음
  • 405: 메서드가 지원되지않음
  • 406: 클라이언트가 받아들일 수 없는 리소스일 경우
  • 407: 프락시를 거쳐서 인증해야될 때
  • 408: 타임아웃(요청을 수행하기 위한 시간이 너무 오래걸릴 때)
  • 409: 충돌 우려
  • 410: 예전에는 갖고있던 리소스인데 지금은 없다.
  • 411: Content-Length 헤더를 추가해야된다
  • 412: 요청 조건 중 하나가 실패할 때 
  • 413: 요청 본문크기가 너무 큼
  • 414: 요청 URI 크기가 너무 큼
  • 415: 서버가 알아들을 수 없는 entity가 요청에 포함된다.
  • 416: 리소스 요청범위가 잘못됐다.
  • 417: Expect 요청헤더에 서버가 응답할 수 없을 경우

---

• 500번대: 서버 에러 상태코드
  프락시가 클라이언트 입장에서 서버와 대화를 시도할 때, 에러가 발생하면 500번대 에러코드를 생성한다.
  
  • 500: Internal Server Error 서버가 요청을 처리할 수 없다
  • 501: Not Implemented 서버가 지원하지 않는 요청이 들어가 있다
  • 502: Bad Gateway 요청 응답연쇄를 타고 들어갈 때 접속이 안될 경우
  • 503: Service Unavailable 현재 요청을 처리해줄 수 없지만 나중에는 가능함. 좀 더 구체적으로는 서버가 Retry-After헤더를 포함시켜 응답하면 언제 그 리소스를 사용할 수 있는지에 대한 정보도 얻을 수 있다.
  • 504: Gateway Timeout - 408이랑 같은데, 프락시나 게이트웨이가 수행하다 발생한 408을 504로 응답해서 클라이언트에게 넘겨준다.
  • 505: HTTP 버전이 안맞는다.

---

헤더

양이 너무 많아서 MDN 문서를 일단 첨부하겠다.

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers

HTTP 헤더 - HTTP | MDN

헤더는 크게 다섯가지로 분류된다.

• 일반 헤더 - 서버, 클라이언트 모두 사용한다. 
  • 일반 캐싱 헤더 - HTTP/1.0때부터 생겨서 로컬 복사본에서 캐시할 수 있게 해주는 헤더다.
• 요청 헤더 - 요청 메시지에서만 의미를 갖는다.
  • Accept 관련헤더 (서버가 필터링 할 수 있도록)
  • 조건부 요청 헤더 - Expect 헤더가 여기에 속한다. Range도 여기 들어있음.
  • 요청보안 헤더 - Cookie, Authorization 이 여기 있다. JWT 토큰을 이용한 통신 할 때 써봤던 기억이 있다.
  • 프락시 요청 헤더
• 응답 헤더 - 응답 메시지에서만 의미를 갖는다.
  • 협상 헤더 - 다국어 지원시 어떤 언어를 받아들일 지 협상하는 것 같다.
  • 응답보안 헤더 - 보안성을 높일 수 있는 Set-Cookie가 여기 있다. 물론 임시 방편이라 나중에는 Session Cookie로 들어가야된다.
• Entity 헤더 - Entity 본문에 대한 헤더로 Content-Type, Content-Length같은게 여기 속한다. 
  • 일반적으로 엔터티 헤더는 메시지 수신자에게 현재 내가 다루고 있는 게 뭔지 알려주는 역할을 한다.
  • 콘텐츠 헤더 - 접두사가 Content인 헤더들이 여기 속한다.
  • 엔터티 캐싱 헤더 - 일반 캐싱 헤더가 언제 어떻게 캐시해야하는 지에 대한 정보면, 이건 엔터티에 대한 정보다. 엔터티가 캐싱된 상태로 유효한지 확인하는 용도로 쓸 수 있다.
• 확장 헤더 - 아직 HTTP 명세에는 추가되지않은 사용자 정의 비표준 헤더

---

커넥션 관리

TCP 커넥션

HTTP 통신은 애플리케이션 계층에 위치하며 컴퓨터나 네트워크가 고장나는 이슈가 아니면 메시지 왜곡이나 문제가 생기지 않는 신뢰성있는 통신이다. 이런 통신은 TCP 커넥션 위에서 돌아간다. 

1. 브라우저가 URL을 통해 리소스를 가져올 서버의 IP주소와 포트번호를 받아 먼저 TCP 커넥션을 생성한다.
2. 커넥션을 생성한 뒤
3. GET이든 POST든 메서드를 이용해 서버로 요청메시지를 보내고,
4. 응답이 오면 브라우저가 그걸 읽은 뒤 커넥션을 끊는다.

이런 TCP 스트림은 세그먼트(전송계층의 단위)로 나뉘어서 IP패킷(네트워크 계층 단위)을 통해 전송되는데, 

TCP 세그먼트 헤더는 TCP 포트번호, TCP 제어 플래그, TCP 순서번호와 무결성을 검사하는 숫자 값(Checksum)을 갖고있고 IP 패킷 헤더는  송신, 수신 IP 주소, 크기 등을 포함한다.

 

컴퓨터는 항상 TCP 커넥션을 여러개 유지하는 데, 이건 포트번호를 통해 이뤄진다. 포트번호는 일종의 게이트웨이 역할을 한다. TCP 커넥션은 발신지 IP주소, 발신지 포트, 수신지 IP주소, 수신지 포트 리엏게 4개의 값으로 식별해 유일한 커넥션을 생성한다. 4개 중 일부가 같은 커넥션은 있을 수 있지만 모두 같은 커넥션은 유일하다.

그래서 서로 다른 커넥션이 같은 포트를 가리킬 수 있다. HTTP는 보통 포트번호 80을 사용하는데 HTTP 통신에 사용되는 TCP 커넥션은 포트번호 80을 가리키고 있다고 할 수 있다. 

소켓 통신도 실습으로 잠깐 했었는데, 아래 도식을 참고하면 이해가 잘 된다.

Client가 connect하려면 Server가 listen(소켓 커넥션을 생성하고 요청 대기) 중이어야 함은 자연스럽다.

HTTP 트랜잭션은 위에서도 서술했는데, TCP 성능에 영향을 받는다. 

sequenceDiagram
    Client-->Client: 브라우저에서 DNS를 찾아 hostname을 IP주소로 변환한다.
    Client->> Server: TCP커넥션 요청
    Server->>Client: TCP커넥션 허가 응답 -- 이 과정에서 커넥션이 많아지면 delay 생김
      Client->> Server: HTTP 요청
Client->> Server: 당연히 이때도 시간이 소요된다.
Server->> Client: 
	Server->> Client: HTTP 응답
 Client-->Client: 종료

소요되는 시간은 하드웨어, 네트워크, 메시지 크기, 서버-클라이언트 간 물리적 거리 등 많은 요소로부터 영향을 받는다.

이런 성능을 관리하기 위해서는 아래와 같은 성능관련 요소를 알고 있어야한다.

• TCP 커넥션의 handshake 설정
• 혼잡 제어용 TCP Slow-start
• nagle 알고리즘
• 확인 응답 지연 알고리즘
• time-wait 지연과 포트 고갈

// 추후 추가 [4.2.3~ 4.3)

HTTP 커넥션 관리

HTTP는 클라이언트와 서버 사이에 중개서버가 놓이는 걸 허락하는데, 중개서버랑은 옵션을 적용하지 않고, 인접한 커넥션에만 옵션이 적용되는 것을 원할 때가 있다. 이때 HTTP Connection 헤더필드는 커넥션 토큰을 쉽표로 구분해 갖고있다.

Connection 헤더에는 

• HTTP 헤더 필드 명 - 이 커넥션에만 해당되는 헤더 나열
• 임시 토큰 값 - 커넥션에 대한 비 표준 옵션
• close 값 - 작업이 완료되면 커넥션을 종료시킬지에 대한 필드.

이 세 종류의 토큰이 전달될 수 있다. Connection 헤더에는 홉(각 서버, 라우터) 별 헤더명을 기술하고, 이 홉 별 헤더명을 통해 원래 Connection 헤더가 최종 수신자가 아닌 위치에서 전달되는 것을 방지한다(헤더 보호하기). 모든 헤더 필드는 메시지를 전달하는 시점에 삭제돼야한다. 수신자는 전달받은 커넥션 헤더의 메시지를 통해 기술되어있는 옵션을 적용한다.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection

Connection - HTTP | MDN

Warning: Connection-specific header fields such as Connection and Keep-Alive are prohibited in HTTP/2 and HTTP/3. Chrome and Firefox ignore them in HTTP/2 responses, but Safari conforms to the HTTP/2 spec requirements and does not load any response that contains them.

HTTP/1.1에서는 Connection헤더를 사용해 옵션을 지정하는 것이 허용됐지만 이제 2, 3버전에서는 무시된다.

---

트랙잭션을 순차적으로 처리한다고 가정하자. 여러 이미지를 받아야되는데 순차적으로 이미지를 받아오면 물리적 지연도 있지만, 사용자가 느낄 때 동시에 조금씩 나오는 것보다 느리다고 생각할 것이다. 또 객체가 다 도달해야 화면을 그릴 수 있기 때문에 그 전에는 화면이 비어있다는 단점도 있다. 

 

순차처리 말고 어떻게 트랜잭션을 처리해야 성능을 높일 수 있을까?

병렬 커넥션

여러개의 TCP 커넥션을 맺고 동시에 HTTP 요청을 보낸다. 

graph LR
	Server --> Client

이게 원래 방식이었다면

graph LR
	Server --> Client
    	Server --> Client
        	Server --> Client
            	Server --> Client
                	Server --> Client

커넥션을 여러개 달아서, 각 커넥션마다 컴포넌트를 내려받아서 웹 페이지가 리소스 가져오는 속도를 더 빠르게 한다.

이러면 순차로 딜레이*N 회 걸리던 게 각 커넥션의 지연시간을 겹치게 할 수 있으므로 속도가 빨라지고, 인터넷 대역폭도 한 커넥션이 점유하는 게 아니라 나눠서 쓴다. 

sequenceDiagram
    Client->> Server: 요청
    Server->>Client: 응답
    Server-->>Client: 응답
    Server-->>Client: 응답
        Server-->>Client: 응답

그러면 병렬 커넥션은 항상 빠를까? 물리적인 이유로 서버의 성능이 좋지 않거나(버틸 수 있는 부하의 양이 적은 경우) 네트워크 대역폭이 좁은 경우 각 객체를 내려받는 속도 자체가 느리기 때문에 오히려 커넥션을 생성하는 시간이 성능을 더 악화시킬 수 있다.

지속 커넥션

커넥션을 재활용하면서 매번 생성/종료 하던 시간을 줄인다. 웹 클라이언트는 보통 같은 사이트에서 여러개 커넥션을 맺는다. (특정 리소스에 자주 참조하니까 참조 지역성이랑 비슷한 개념이라는 생각이 든다.) 이걸 웹에서는 사이트 지역성이라고 하는데 HTTP/1.1에서는 처리가 끝나도 서버, 클라이언트 둘 중 어느 한 쪽이 끊지 않는 이상 커넥션을 유지해서 재사용할 수 있고 이걸 지속 커넥션이라고 한다. 이러면 커넥션을 생성/소멸하는 데 드는 비용을 줄 일 수 있으므로 성능을 조금 더 올릴 수 있다. 단점은 커넥션이 유지되기 때문에 커넥션이 쌓이면서 발생할 리소스 소모를 어떻게 관리할 것인지에 대한 문제가 있다는 것이다.

병렬+지속을 사용하면 적은 수의 병렬커넥션을 지속 커넥션으로 쓰면서 장점을 극대화 시킬 수 있다. 커넥션 타입으로는 keep-alive(1.0+)와 persistent 커넥션(1.1)이 있다.

Keep-Alive

HTTP/1.1 200 OK
Connection: Keep-Alive

1.0 버전에서 지속 커넥션을 위해 사용된 헤더다. 1.1부터는 keep-alive가 기본이라서 명세에는 뺐지만 아직도 사용되고 있고 keep-alive를 헤더에 담아서 요청보낸 클라이언트는 서버 응답의 Keep-Alive 여부에 따라 커넥션을 끊을지 말지 결정한다. 없다면 서버가 끊을 것으로 추정하고 클라이언트도 커넥션을 유지하지않는다. 이 모든 과정은 강제성이 없다. 단순히 요청일 뿐이고 keep-alive 자체에 대한 옵션도 Keep-Alive헤더를 이용해 설정할 수 있다. 

Keep-Alive: timeout=5, max=10

최대 10개의 트랙잭션이 처리될 동안 커넥션을 유지하고, 최소 5초간 커넥션을 유지하라는 옵션이다. 

커넥션 유지는 Content-Length를 통해 이뤄지는데 그 이유는 엔터티 본문 길이를 통해 트랜잭션 중에 기존 메시지 시작점과 끝점을 알 수 있기 때문이다. 

 

문제는 다른 곳에서 생긴다.

오래된 프락시 서버를 사용한다면, Connection 헤더를 인식하지 못해 keep-alive를 알아듣지 못한다. 무조건 전달을 수행하는 프락시 특성 상 이해하지 못한채로 요청 그대로 다음 프락시로 전달하고 계속 전달하다가 웹 서버까지로 메시지가 도착한다.

문제 원인는 Connection 헤더가 hop 별 헤더기 때문에 한 개의 전송링크에만 적용된다는 점이다. 이 말은 서버가 클라이언트랑 keep-alive를 맺는게아니라 프락시랑 맺는 다는 말이다. 그러면 프락시는 keep-alive를 줄 수 없는데 서버는 keep-alive 커넥션을 맺고 있으니 다음 클라이언트의 요청이 와도 서버에 들어가지 않고 대기상태(Hang)로 들어가버리고 타임아웃이 날때까지 커넥션을 유지한다. 

=> 방지책은 프락시한테 Connection 헤더 관련을 일체 전달하지 않는 것이다. 

Proxy-Connection

Proxy-Connection 헤더가 등장한 이후로는  위 상황과 같은 경우를 걱정하지 않아도 된다. Proxy-Connection은 확장헤더로 이건 웹 서버에 전달해도 무시되는 헤더다. dumb proxy가 아닌 프락시 서버(Connection 헤더를 이해하는)가 Proxy-Connection헤더에서 keep-alive를 읽어 Connection 헤더로 바꿔 웹 서버로 전달하게 되면 Hang없이 잘 작동할 것이다.

하지만 문제가 아직 존재한다. 하나의 프락시만 서버-클라이언트 사이에 존재한다면 문제가 없는데, 두개의 프락시를 거친다고 가정하면 이전에 있던 문제가 여전히 발생한다.

 

이런 설계상의 문제를 해결하기 위해서 1.1버전 부터 persistent 커넥션을 지원한다. default가 모두 persistent 커넥션으로 설정되어있고 커넥션을 끊으려면 헤더에 Connection: close를 명시해야된다. 

파이프라인 커넥션

좌측이 그냥 persistent connection, 오른쪽이 pipelining 적용한 connection

공유 TCP 커넥션을 하나 두고 그걸로 병렬 HTTP 요청을 보낸다. 이때 사용되는 커넥션이 지속 커넥션(persistent)을 이용하는 방법이다. 응답이 도착하기 전에 요청을 서버 큐에 쌓아두고 응답도 한번에 주르륵 받는다. 

지속커넥션이 아니면 파이프라인 방식을 사용할 수 없고(순서번호가 없어서 순서를 유지할 수 없기 때문에) 요청-응답순서는 똑같아야된다.  또 파이프라이닝 중간에 끊기면, 다시 커넥션을 맺어 요청을 이어갈 수 있어야한다. 

파이프라인으로 보내도 에러가 나지는 않지만 위험한 요청으로는 POST같은 결과값을 변화시키는 요청이다. 이런 요청은 서버 데이터에 변화를 주기 때문에 파이프라인을 통해 보내면 위험하다. 서버 데이터에 영향을 끼치지 않는(등록 삭제는 같은 결과를 반환하지만 POST는 중복으로 들어갈 수도 있으므로 매번 다른 결과를 반환할 수 있다.) 트랜잭션을 멱등하다고 한다. GET이 멱등하다고는 하지만 동적인 값을 GET해오는 경우에는 비멱등이라고 할 수 있다.

커넥션 끊기

보통 에러가 발생하면 끊기는 것 외에도, 에러가 없어도 언제든 끊을 수 있다. 요청 데이터 전송 후 응답이 오기 전에 커넥션이 끊기면 서버에서 요청을 얼마나 처리했는지 전혀 알 수 없다. 그래도 끊을 수 있다...

HTTP 응답에는 Content-Length 헤더가 있고, 이 크기정보를 이용해서 데이터 전송이 아직 남았는지(커넥션을 유지해야하는지) 판단하는 근거가 되기도 한다. 

우아한 커넥션 끊기

애플리케이션은 TCP 입력 채널과 출력 채널 중 한 개만 끊거나 둘 다 끊을 수 있다.

• 전체 끊기: close()를 호출하여 TCP 커넥션의 입력 채널과 출력 채널의 커넥션을 모두 끊음
• 절반 끊기: shutdown()을 호출하여 입력 채널이나 출력 채널 중에 하나를 개별적으로 끊음

클라이언트가 이미 끊긴 입력 채널에 데이터를 전송하면 connection reset by peer 메시지를 받고, 대부분의 운영체제에서 이를 심각한 에러로 취급하여 아직 읽히지 않은 버퍼의 데이터를 모두 삭제한다. 파이프라인 커넥션에서는 이 상황이 특히 더 악화된다. 이게 리셋 에러다. 그래서 클라이언트가 데이터를 더 보내지 않을 것임을 확신할 수 없다면 커넥션의 입력채널을 끊는 건 위험하다.

 

에러 발생을 예상하기 위해 ‘절반 끊기’를 사용해야 한다. 이걸 우아하다고(?) 표현한다. 보통 자신의 출력 채널을 끊고 다른 쪽의 출력 채널이 끊기는 걸 기다린다. 양 쪽에서 모두 끊어두면 리셋 위험 없이 커넥션이 완전히 종료된다. 문제는 상대방이 절반끊기를 구현하지 않은 경우인데 이 상황에 대비하려면 송신측에서 절반끊기를 하고, 다른 쪽 입력채널에 대한 상태검사를 주기적으로 하면서 끊겼나 확인해야된다. 만약 입력 채널이 특정 타임아웃 내 끊어지지 않으면, 애플리케이션은 리소스 보호를 위해 강제로 커넥션을 끊을 수도 있다.

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요! 로그인 안해도 됩니다 ^_^