[면접준비]서버 성능 향상 - 0

성능

클라이언트를 제외한 서버군 전체가 상호작용 하며, 클라이언트의 요청을 처리하는 능력을 의미한다.

클라이언트 측면에서는, 단위 시간 당 요청 처리량을 의미하며, 서버 측면에서는 클라이언트의 수용량을 의미한다.

지연과 대역폭

지연은 송신지에서 수신지로 메세지를 보내는데 도착하는 시간을 의미한다. (지연 = 전파시간 + 전송시간 + 큐시간)

 - 전파시간 : 한 노드에서 다른 노드로 데이터가 전달될 때 통신 링크 상에서 걸리는 시간 (발사 이후, 도착지까지 도착하는 시간)

 - 전송시간 : 노드에서 노드로 데이터를 전송할 때의 시간 (발사 준비 시간)

 - 큐지연 : 데이터가 전송되기 위해 라우터의 출력포트에서 기다리는 시간 (발사 대기 시간)

대역폭은 한번에 많은 패킷을 보낼 수 있는지를 의미한다. 예를들어 5G에서 대역폭이 높아서 속도가 빠르다는 것은 같은 양의 데이터를 보낼 때, 

많은 데이터를 보낼 수 있어 빠르다는 것을 의미한다. 대역폭이 높으면 더 많은 클라이언트를 수요할 수 있다.

웹 자원 캐시 - HTTP 응답 상태 코드 (참고 자료 : https://lkhlkh23.tistory.com/92?category=820544, https://cyberx.tistory.com/9)

(1) 304 - Not Modified

클라이언트가 요청한 데이터가 캐시에 있는 최신 데이터인 경우 클라이언트에게 전달하는 상태코드이다. 304 Not Modifed는 Body를 포함해서는 안된다.

 - LAST-MODIFIED

  a. 브라우저는 최총 응답에서 받은 LAST-MODIFIED 값을 헤더의 IF-MODIFIED-SINCE에 포함시켜 페이지를 요청한다.

  b. 캐시는 요청된 파일의 수정시간을 IF-MODIFIED-SINCE 값과 비교하여 더 최신이면 304 Not Modified 응답을, 그렇지 않으면 서버로부터 최신 파일을 받아

     클라이언트에게 200 OK 응답을 전달한다. 캐시의 동일한 파일에 대해 수정시간을 변경한다.

 - Cache-Control, Age, Expire

 - ETag

(2) 200 - OK

클라이언트의 요청이 성공적이었으며, 서버는 요청한 데이터를 포함하여 응답한 경우에 전달하는 상태코드이다.

HTTP 압축

Accept Encoding은 클라이언트가 서버에게 요청을 보낼 때, 클라이언트가 서버로부터 전달받은 페이지를 복호화할 수 있는 압축방법을 제시한 것이다.

예를들어, Accept-Encoding : gzip 이라고 한다면, 서버의 응답을 인코딩할 수 있는 압축 방법은 오직 gzip 이라는 것이다.

반대로 Content-Encoding은 서버가 클라이언트에게 전달하는 응답이 인코딩된 방식을 의미한다. 결국은 클라이언트에게 해당 방식으로 Encoding 하라는 것이다.

압축은 대역폭의 영향을 미치는 요소이다. HTTP 압축을 효과적으로 전송되는 패킷의 크기가 감소해서 대역폭이 감소하며, 대역폭 감소를 통해 수용할 수 있는

사용자의 수도 증가한다는 것이다. 또한, 대역폭을 높이기 위한 비용도 감소시킬 수 있다. 그리고 응답 패킷의 크기가 감소되었기 때문에 응답속도 빨라진다.

그렇다면 HTTP 압축에도 비용이 발생한다고 생각할 수 있다. 물론 발생한다. 하지만, 응답 패킷의 크기를 작게 해서 지연을 감소시켰을 때 얻는 효과가 더 크다.

그렇다면 무조건 HTTP 압축을 하는 것이 효과적일까? 꼭 그렇지만은 않다. 만약 충분한 대역폭이 제공한다고 하면 굳이 압축할 필요가 없다.

압축을 하여 추가적인 오버헤드가 발생할 뿐이다. 

방금과는 말이 좀 다르다고 생각할 수 있다. 압축하는 오버헤드보다 지연을 감소시키는 것이 더 효과적이라는 것이다. 오버헤드가 발생하지 않는게 아니라!

그리고 HTML, CSS, JS와 같은 텍스트 기반의 자원은 압축하는 것이 효과적이다. 그러나 GIF, JPG와 같은 이미지는 이미 충분히 압축이 되었기 때문에 압축을 

하면 오히려 압축에서 오버헤드가 발생할 수 있다.

HTTP Connection

파이프 라인은 응답 메세지가 도착하지 않는 상태에서 연속적인 요청 메세지를 서버에 전달하는 방식이다. 서버는 요청 메세지를 받는 순차적으로 응답을 

보낸다. 연결과 종료하는 과정을 줄임으로서 네트워크 자원의 절약할 수 있다. 

HTTP는 비연결성 방식으로 요청/응답 후에는 연결을 종료하고, 다시 연결을 반복하는 구조이다. 이는 네트워크 비용 측면에서 많은 비용을 발생한다.

실제로 데이터를 주고받는 과정보다 연결/종료 하는 과정에서 더 많은 비용이 발생한다고 한다. 그래서 이런 단점을 보완하고자 HTTP 1.1 부터는 KEEP-ALIVE

기능을 제공한다. KEEP-ALIVE는 클라이언트와 서버의 연결을 유지하는 방법이다. 연결된 소켓에 접근한 마지막 시간으로부터 타임아웃 시간까지 요청이 

없더라도 계속 대기하는 구조이다. 결국은 타임아웃시간까지 요청이 있다면 계속 연결된 상태를 유지할 수 있다.

(연결되어 있는 소켓 포트에 계속해서 데이터를 전송하는 구조)