정리하기 위한 블로그 정리하기 위한 블로그

TCP 사용되는 Keepalive 개념과 HTTP/1.1에서 사용되는 Keepalive의 개념이 어떤 차이가 있을까 TCP의 Keepalive와 HTTP의 Keepalive는 둘 다 하나의 커넥션으로 데이터를 주고 받는 점에서는 같다고 볼 수는 있다. 하지만 목적과 특성이 다르다. TCP Keepalive는 서버와 클라이언트 간의 연결을 유지하기 위한 목적이 있다. 반면 HTTP Keepalive는 불필요한 새로운 연결을 줄이고 기존 연결을 재사용함으로써 성능을 높이는 데에 목적이 있다. 또한 TCP Keepalive는 일정 시간 간격으로 payload가 없는 (0 or 1byte) 데이터를 전송하여 커넥션이 살아있나 확인하고 미리 설정된 일정 시간만큼 커넥션을 연장한다. 이는 좀비소켓을 방지하는 데에도..

흔히 사용되는 소켓 옵션을 정리한다. SO_KEEPALIVE 이 옵션을 활성화하면 상대방에게 약 2시간 간격으로 TCP 패킷을 보낸다. 이 패킷에 대해 상대가 ACK 패킷으로 응답하면 응용 프로그램에 통보 없이 커널 선에서 살아 있음 확인하고 마무리한다. 아무런 응답이 없거나 RST 패킷을 받으면 자동으로 소켓을 닫는다. TCP 연결에서는 데이터 교환이 없는 건지, 상대 시스템이 다운되거나 네트워크 연결이 불가능한지 알 수 없다. 소켓 생성이 늘어나면 시스템 자원 소모도 비례해서 늘어나므로 연결이 끊어진 소켓을 닫아줄 필요가 있다. 이때 SO_KEEPALIVE를 설정하여 주기적으로 불필요하게 열린 소켓을 닫을 수 있다. 하지만 커널에서 주기가 보통 2시간으로 되어 있기 때문에 비정상적인 종료를 빠른 시간..

혼잡제어 : 송신측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법 혼잡제어 - AIMD(Additive Increase / Multicative Decrease), - Slow Start, - Fast Retransmit(빠른 재전송), - Fast Recovery(빠른 회복) 혼잡 방지 알고리즘 - TCP 타호와 TCP 리노 - TCP 베이거스 배경 - 각 호스트는 보낼 수 있는 최대의 패킷을 보내고 일부 라우터는 정해진 시간내에 받은 패킷을 처리하지 못했다 정해진 시간내에 패킷이 처리되지 못하면 호스트는 패킷을 재전송하였고, 라우터는 더 많은 패킷을 받게되어 혼잡현상이 더 심해졌다. TCP 혼잡제어는 보내는 측에서 네트워크 수용량을 결정하는 방식으로 동작한다. 네트워크 수용량..

송신자의 데이터 전송 속도가 수신자의 데이터 처리 속도보다 느릴 경우에는 심각한 문제가 발생하지 않는다. 그러나 송신자의 데이터 전송 속도가 수신자의 데이터 처리 속도보다 빠를 경우에는 심각한 문제가 발생할 수 있다. 수신자가 데이터를 아직 처리하지 못했는데, 송신자는 계속해서 데이터를 전송한다. 물론 이런 경우를 대비해 수신자는 버퍼를 마련해서 데이터를 차곡차곡 저장한다. 그런데 만약 이 큐를 꽉 채우고도 남을 정도로 송신자가 데이터를 전송한다면 어떨까? 그러면 그냥 그대로 데이터를 잃어버리는 것이다. 그래서 우리는 데이터 손실을 없애야 한다 => 이를 위해 수신자가 자신의 상태를 송신자에게 알린다. 흐름제어 : 송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법 혼잡제어 : 송신측의 데이터..

- 동시에 수천만의 사용자가 하나의 서버에 요청을 한다면 서버가 다운될 수 있다. 두 가지 해결방법 존재 서버의 성능을 올리던가 = Scale-up 여러대의 서버를 둬서 나눠서 일을 하던가 = Scale-out Load Balancing이란? - 하나의 인터넷 서비스가 발생하는 트래픽이 많을 때 여러 대의 서버가 분산처리하여 서버의 로드율 증가, 부하량, 속도저하 등을 고려하여 적절히 분산처리하여 해결해주는 서비스 * 사전 개념* 네트워크 구조에 상관없이 개방형으로 통신할 수 있는 국제 표준 모델이 OSI 7layer입니다. L1~ L7 까지 나뉘어져있고 L4 장비 등의 말이 여기서 유래된 것입니다. L1 은 '랜선' 등의 장비를 의미하는 것이고 L2는 'Mac address', L3는 'IP'를 의미한..