CS39 스패닝 트리 프로토콜 먼저 스패닝트리란, 그래프의 모든 정점을 포함하면서 루프가 없는 부분그래프(=트리)를 말한다. 하나의 그래프는 여러 스패닝 트리를 가질 수 있는데, 예를 들어 좌측의 그래프는 우측의 두 스패닝 트리를 가질 수 있다. (물론 더 있다) 그리고 최소 스패닝 트리는 여러 스패닝 트리 중에서도 가중치의 합이 최소인 녀석을 말한다. 스패닝 트리 프로토콜은 이름에서도 알 수 있듯 스패닝 트리를 만들기 위한 프로토콜이다. 그리고 네트워크는 그래프와 형태가 유사하고 실제로 토폴로지를 그래프로써 표현하곤 한다. 만일 스패닝 트리 프로토콜을 통해 네트워크(그래프)에서 스패닝 트리를 뽑아낼 수 있다면, 모든 노드가 연결되어 있으면서 루프가 없는 이상적인 네트워크가 구성되는 것이다. 다만 스패닝 트리 프로토콜은 Layer 3.. 2023. 10. 8. 게이트웨이 이중화 프로토콜 First Hop Redundancy Protocol (말그대로 첫 홉=게이트웨이의 이중화를 위한 프로토콜)은 크게 3개의 종류가 있다. 1. Cisco 전용 프로토콜인 HSRP (Hot Standby Routing Protocol) 2. IETF 표준인 VRRP (Virtual Router Redundancy Protocol) 3. 위 둘과는 달리 로드 밸런싱을 기반으로 하는 GLBP (Gateway Load Balancing Protocol) 1,2는 다수의 gw중에서 하나의 gw만을 사용(Active)하고 나머지는 대기(Standby)하는 방식이나 3은 모든 gw를 사용하면서 로드 밸런싱이 이루어지기 때문에 설정이 보다 복잡하다. 관리자는 단일 장애점을 회피하기 위해 gw를 이중화한다. 하지만 엔드.. 2023. 10. 7. NAT 방식의 구분 위키백과에서 사진을 가져왔는데 조금 이해하기 힘든 부분이 있어서 나만의 설명을 조금 덧붙여보았다. Full Cone 기본적으로 NAT(NAPT)는 패킷이 NAT 장비를 거쳐 Outbound될 때 포트를 매핑한다. 그리고 매핑 정보는 테이블에 기록되어 다시 Inbound될 때 이를 참조하고 패킷을 포워딩하게 된다. Full Cone은 가장 느슨한 정책으로 한번 포트가 매핑되면 누구든지 접근할 수 있는데, 이는 상대방의 정보까지는 매핑하지 않기 때문이다. Restricted Cone Full Cone과는 달리 상대방의 IP를 함께 매핑하므로 패킷의 송수신에 제한이 있다. 좌측 그림을 보면 클라이언트는 Server 1에게 송신한 기록이 있으므로 Server 1으로부터 패킷을 수신할 수 있다. 하지만 Serve.. 2023. 7. 17. STUN-TURN과 NAT의 관계 STUN과 TURN은 주로 VoIP나 WebRTC를 다룰 때 나오는 주제인데, 그 근본적인 원인은 NAT에게 있다고 할 수 있다. VoIP를 예로 들면, App. Layer 프로토콜인 SIP와 SDP로 세션을 수립할 때 자신의 IP, Port를 담아서 보내는데 일반적인 NAT는 이를 커버해주지 않으므로 STUN과 TURN이 필요한 것이다. 그렇다면 일반적이지 않은 NAT를 사용하면 되는게 아닌가? 싶겠지만 그 기능(ALG)에는 여러 문제가 있다. 궁금하다면 다음의 링크를 참고하시라. SIP ALG and why it should be disabled on most routers | VoiceHost 아무튼, STUN과 TURN에 대해 알아보자면... VoIP 네트워크를 위와 같이 구성했다고 치자. 그러면.. 2023. 7. 9. 네이글(Nagle) 알고리즘이란? 네이글 알고리즘이 처음 소개된 RFC 896을 보면... 작은 패킷과 관련하여 특수한 문제가 있다. 키보드로 작성한 단일 문자를 TCP로 전송하면 일반적으로 41 바이트(1 바이트의 데이터, 40 바이트의 헤더)의 패킷이 된다. 이 4000%의 오버헤드는 짜증나지만 부하가 적은 네트워크에서는 견딜만한 수준이다. 그러나 혼잡한 네트워크에서는 이 오버헤드로 인해 손실, 재전송 등의 문제가 발생할 수 있다. 실제로 처리량이 너무 낮아지면 TCP 연결이 중단될 수도 있다. 라는 내용이 있는데, 요약하자면 1 바이트를 보내려고 수십 바이트의 헤더를 덧붙이는 게 싫다는 말이다. 이는 타이머 등을 활용해서 해결할 수도 있었지만 여러 문제가 있었기에, John Nagle은 아래의 해결책을 제시한다. ⋯간단하고 우아한 .. 2023. 5. 19. TCP 상태 전이도 설명 소켓 프로그래밍을 해봤다면 이해가 조금 수월할 것이다. 서버의 입장에서는, 소켓을 Listen 상태로 전환한다. (LISTEN) SYN을 수신하고 SYN+ACK를 송신한다. (SYN RECEIVED) ACK를 수신한다. 클라이언트 소켓이 Accept 된다. (ESTABLISHED) 데이터를 송수신한다. FIN을 수신하고 ACK를 송신한다. (CLOSE WAIT) FIN을 송신한다. 소켓을 Close하려 한다. (LAST ACK) ACK를 수신한다. 소켓을 Close 한다. (CLOSED) 위의 흐름이 가장 일반적이다. 이는 다이어그램의 파란 선을 따라간 것이고, 회색 선을 따라가면 일반적이지 않은 전이가 보인다. 대표적으로, 서버가 먼저 SYN을 송신한다. (SYN SENT) 서버가 먼저 FIN을 송신한.. 2023. 5. 18. 정지 문제(Halting problem)의 간단한 증명 증명을 위해 정지 문제를 판별할 수 있는 함수 H가 존재한다고 하자. (귀류법) 함수 H는 판별할 함수 I를 인자로 받는다. 이 때 함수 J를 아래와 같이 정의하면 모순이 발생한다. J의 인자로 J를 제공하면, - H(J)가 참이라면 J는 언젠가 끝난다는 뜻이지만 J는 무한루프에 의해 끝나지 않는다. - H(J)가 거짓이라면 J는 끝나지 않는다는 뜻이지만 J는 return문에 의해 끝나게 된다. 따라서 이는 모순이다. 2023. 4. 28. 2-way handshake를 사용하지 않는 이유? 3-way handshake에 대해 알아보다 문득 2-way를 사용하지 않는 이유가 궁금해졌는데, 이에 내가 알아본 바를 간략하게 정리해보려고 한다. 위 그림처럼 timeout이 발생하면 isn이 어긋나게 된다 구글에 2-way handshake를 검색하면 바로 나오는 그림인데, 뭔가 그럴듯해 보인다. 그러나 아무리 눈을 씻고 찾아봐도 2-way에 대한 ieee 표준은 찾아볼 수가 없으니... 따라서 저 그림도 표준은 아닐 것이고, 실제로 서버가 ACK+SYN을 보내면 해결되는 문제다. 신뢰할 수 없다 호스트의 입장에서 연결을 신뢰하려면 아래 사항이 모두 확인되어야 한다. (1) 상대방에게 패킷을 전달할 수 있다. (2) 상대방으로부터 패킷을 전달받을 수 있다. 그러나 2-way에서는 일부만 확인된다. .. 2023. 4. 18. 이전 1 2 3 4 5 다음
