TCP Congestion
TCP는 임의로 네트워크를 파악, 전송속도와 전송률을 조절할 수 있다. 또한 TCP는 안전한 통신을 보장하는데 이는 패킷을 받았다는 ack가 오는데 이를 받지 못하면 받을 때 까지 계속 재전송하는 기술이다.
UDP는 이 어떠한 과정도 하지 않는다.
따라서 TCP와 UDP 뭘 쓸지는 본인 자유지만, 이 실제로는 UDP가 더 많이 쓰인다.
Unfairness
TCP는 그 특성상 네트워크 트래픽이 가득차면 자리를 내어준다. 근데 UDP는 그런거 신경 안쓰니깐 어느 순간 UDP가 모든 트래픽을 다 먹어버리지 않을까?
아무튼 안그런다고 하는데 이는 나중에 더 알아보자
Multiplexing, Demultiplexing
Multiplexing 여러 프로세스가 보낸 메시지를 모아서 한번에 다른 호스트로 전달해주는것이고,
DeMultiplexing은 이 모아서 받아온 메시지를 알맞게 배분해준다
디멀티플렉싱, 즉 분배를 위해서는 포트번호가 반드시 필요하다.
UDP에서의 Demultiplexing
다른 IP에서 같은 포트로 보낼 때 두개다 똑같은 소켓으로 받는다.
이때 총 destination IP address, destination port 2개가 필요하다.
IP/UDP datagrams with same dest. port #, but different source IP addresses and/or source port numbers will be directed to same socket at receiving host
TCP에서의 Demultiplexing
즉, connection oriented multiplexing이다.
출발지 IP랑 포트, 도착지 IP랑 포트로 구분한다.
요약
Multiplexing, demultiplexing: based on segment, datagram header field values
UDP: demultiplexing using destination port number (only)
TCP: demultiplexing using 4-tuple: source and destination IP addresses, and port numbers
Multiplexing/demultiplexing happen at all layers
UDP 헤더분석
- Source port. Dest port : 포트번호
- Length : 헤더포함 세그먼트의 길이
- Checksum : 에러가 있는지 없는지 체크헤주는 기능
- 예를 들어 5, 6 이 오면 합해서 11임 이 값이 체크함
- 해봤자 이건 16비트밖에 안댐 이걸 다 확인할 수 있을까?
해결책 : 두 값을 2진법으로 변환하고 다 더함
이러면 보통 17비트가 되는데 맨 앞자리를 맨 뒷자리에 더해서 해결
하지만 56이 47이 되는경우를 잡아낼수는 없음
CheckSum
에러검증을 위한 기능이다. 다만, 위에서 설명한거서처럼 정확도가 떨어진다.
아스키에서는 이를 검증하기위해서 7자리 + 맨 앞자리에 뒤에 있는 1의 개수를 짝수로 맞춰주는 비트를 넣는다. > Parity Check
이건 50%짜리 검증방법이다.
UDP는 여기서 더 발달해서 16비트짜리로 검증을 하지만, 그래도 쉬운 오류도 못잡아내는 허접알고리즘이다.
CRC라는 오류검증용 코드를 사용한다. 나눗셈으로 하는데 나눗셈을 해서 나머지까지 똑같을 확률이 매우 적다.
