HTTP 1.0+ : keep-alive
http 1.0에서는 keep-alive라는 이름으로 구현됨.
javascript
요청 메시지에 다음 헤더를 넣어 작동.
Connection : keep-alive
서버가 계속 이 커넥션을 통해 메시지를 받고 싶다면, 응답 메시지에 같은 헤더를 포함
Connection : keep-alive
javascript
다음 헤더을 통해 keep-alive의 세부사항을 제어한다.
이 헤더는 Connnection : keep-alive 헤더가 있을 때만 사용 가능.
Keep-Alive: timeout=5, max=99
* timeout : 커넥션이 얼마나 유지될지, 그 시간을 결정.
* max : 최대 몇 개의 http 트랜잭션을 처리할 때까지 유지될 것인지 의미.
단, 이대로 동작한다는 보장은 없다.
서버 자원은 무한정이 아니다. 그렇기 때문에 이러한 접속을 계속 유지하는 것은 Server에 손실을 발생시킨다.
즉 서버와 연결을 맺을 수 있는 Socket은 한정되어 있고 연결이 오래 지속되면 다른 사람들이 연결을 못하게
되는 상황이 닥친다. 이를 위해 다음과 같은 옵션을 넣어준다.
keep-alive 커넥션: 규칙
javascript
<규칙>
1. 반드시 "Connnection : keep-alive" 라는 헤더가 있어야 함.
중간에 하나라도 이 헤더가 없으면 커넥션이 끊어짐.
2. 엔터티 본문의 길이를 반드시 명시해야 함.
즉 "Content-Length" 가 필수로 있어야 하고, "multipart media type"을 가지거나
"chunked transfer encoding"으로 인코드 되어야 함.
3. 프락시와 게이트웨이는 Connection 헤더의 규칙을 철저히 지켜야 함.
메시지를 전달하거나 캐시에 넣기 전에 Connection 헤더에 명시된 모든 헤더 필드와
Connection 헤더를 제거해야 함.
4. 정석대로라면, keep-alive 커넥션은 Connection 헤더를 인식하지 못하는 프록시 서버와는 맺어지면 안됨.
멍청한 프록시를 막기 위한 것이지만, 현실적으로 쉽지 않음.
5. HTTP 1.0을 따르는 기기로부터 오는 모든 Connection 헤더 필드는 무시해야 한다.
오래된 프락시 서버로부터 실수로 전달될 수 있기 때문.
6. 클라이언트는 응답 전체를 모두 받기 전에 커넥션이 끊어진 경우 별다른 문제가 없으면
다시 요청을 보낼 수 있게 준비되어야 함.
keep-alive 커넥션 : 장점과 단점
javascript
<장점>
커넥션을 맺고 끊는 데 작업이 없어졌기 때문에 시간이 단축된다.
<단점>
정적 자원(HTML, 이미지 파일 등)으로만 구성된 웹 서버에 Keep Alive을 사용할 경우 약 50%의 성능 향상을 보인다고 한다.
위와 같은 성능 향상을 보이려면 서버가 바쁘지 않아야 하는데 바쁜 서버 환경에서 Keep Alive 기능을 사용할 경우
모든 요청마다 연결을 유지해야 하기 때문에 프로세스 수가 기하급수적으로 늘어나 MaxClient값을 초과하게 된다.
따라서 메모리를 많이 사용하게 되며 이는 곧 성능 저하의 원인이 된다.
즉 대량 접속 시 효율이 떨어지게 된다.
문제점 : 멍청한 프록시 -> "지속 커넥션 - http 1.0 : keep-alive(2)"에서 계속...