기본 콘텐츠로 건너뛰기

라벨이 tcp인 게시물 표시

TCP KeepAlive (퍼옴)

개요: TCP Keepalive 해설 세부 설명: Sun Microsystems는 TCP keepalive 매개 변수(tcp_keepalive_interval)를 15분 미만으로 설정하는 것은 바람직하지 않다고 봅니다. 이제 TCP keepalive를 설명한 후에, 왜 그것이 바람직하지 않은지 몇 가지 이유를 설명할 것입니다. 우선, keepalive가 TCP의 필수 요소가 아니라는 점을 말하고 싶습니다. keepalive는 TCP 규격에 나오는 옵션 기능의 하나이며, 제조업체의 재량에 따라 포함시킬 수 있습니다. Sun은 TCP에 이 기능을 포함시키기로 결정했습니다. 하지만 TCP 규격에서는 keepalive 기능을 포함시키는 경우 간격을 최소한 2시간 이상으로 기본 설정해야 한다고 규정합니다. 뿐만 아니라 이 기능을 옵션 기능으로 만들어야 합니다. 바로 그 점 때문에 TCP keepalive를 설정할 것인지 여부를 각 프로그램에게 맡기게 되는 것입니다. 프로그램이 TCP keepalive를 명시적으로 실행하지 않으면, 탐색 패킷(probe)을 보내지 않을 것입니다. TCP keepalive는 setsockopt()을 사용하여 소켓 옵션(SO_KEEPALIVE)을 설정하면 사용할 수 있게 됩니다. 소켓 옵션이 설정되면 tcp_keepalive_interval로 지정된 시간 동안 연결이 유휴 상태가 되었을 때 keepalive 탐색 패킷을 보냅니다. 응답 메시지가 수신될 때까지 또는 tcp_ip_abort_interval로 지정된 시간이 다 경과할 때까지 탐색 패킷을 보냅니다. 응답은 연결 상대측을 지연시키는 요소의 영향을 받습니다. 연결 상대측이 연결을 닫거나 다시 부팅을 하면 응답 메시지는 RST(reset packet)가 됩니다. 수신 주소에 도달할 수 없다는 ICMP 메시지를 수신하게 될 가능성도 있습니다. 라우터가 고장나거나 케이블 연결이 끊긴 경우에 그런 상황이 발생합니다. 그 외에도 많은 가능한 상황이 있습니다. 탐색 패킷 자체...

FreeBSD: Limiting open port RST response from xxx to 200 packets/sec

FreeBSD에서 /var/log/message 안에 "Limiting open port RST response from xxx to 200 packets/sec" 라는 메시지를 볼 수 있다. 외부로부터 잘못된 SYN요청이 과도하게 들어와서 RST로 응답하는 회수를 초당 200건으로 제한했다는 의미이다. 이게 SYN 공격을 통해서 발생할 수도 있지만, 의도치 않게 네트워크 상황에 따라 발생할 수도 있다. 예를 들어 해외에 NAT로 묶인 망이 있고, 그곳에 서비스 이용 클라이언트가 3,000개(순단 시 자동으로 재접속 시도가 있다는 것도 가정!)가 있다는 가정을 해보자. 해외망 특성상 네트워크 순단이 숨쉬기보다 조금 덜 발생 하는데, 위에서 말한 망이 살짝 순단일 경우 동시에 3,000개 접속(session)이 떨궈진다. 이때 거의 한정적인 아이피 - NAT에 묶여 있으니 - 에서 많은 SYN이 발생할 것이다. 게다가 이런 경우 심심치 않게 중간 망이나 NAT쪽 망이 갑자기 부하가 몰려 장비가 앉았다 일어났다를 빠르게 반복할 수도 있다. NAT에 묶인 클라이언트 OS는 connection timeout를 뿜기 전에 SYN을 몇 번 더 보내볼 것이고... 덕분에 서비스를 제공한 서버로 의도와 상관 없이 DDoS SYN attack을 날려주는 멋진 결과를 선사한다. 공격이라고 생각한다면 tcpdump를 이용해서 패킷을 걸러내는 문서 를 참조해보자. Powered by ScribeFire . 원본 위치: http://purewell.egloos.com/3513098

TCP 바로 알기

회사에서 진행하고 있는 FT 구성원과 함께 찍은 사진. 허락 없이 올려도 될라나... 설마 빚쟁이한테 쫓기는 분은 없겠지... 원본 위치: http://purewell.egloos.com/3451501

connect 완료 시점은 accept가 아니다.

흔히 생각하기에 TCP에서 3-way handshaking(SYN→SYN-ACK→ACK)를 완료하는 시점이 accept를 하는 시점이라고 착각하기 쉽다. 그러나 경기도 오산이라는거~* listen시점부터 이미 서버쪽은 3-way handshaking를 할 수 있고, 접속을 완료한 뒤에는 그것을 backlog queue에 고스란히 모셔둔다. accept함수는 큐에서 그것을 긁어올 뿐. 원본 위치: http://purewell.egloos.com/3351468