Cyber Security · मराठी आवृत्ती
TCP विरुद्ध UDP: कुठे कोणता उपयोगी?
“TCP reliable आहे तर सगळं TCP वरच का नाही?” कारण reliability साठी handshake, acknowledgements, retransmission आणि ordering manage करावी लागते. काही live applications मध्ये थोडा data चुकला तरी चालतो, पण उशीर होणं चालत नाही. Protocol निवडताना application ची गरज महत्त्वाची असते.
| Feature | TCP | UDP |
|---|---|---|
| Connection | Connection-oriented (3-way handshake SYN, SYN-ACK, ACK) | Connectionless |
| Reliability | Ordering आणि retransmission; delivery शक्य नसेल तर connection error | Best effort; packets हरवू शकतात |
| Speed / overhead | अधिक control overhead; minimum 20-byte header | कमी protocol overhead; 8-byte header |
| Uses | Web (HTTP/1.1, HTTP/2), SSH, e-mail, databases | DNS, DHCP, VoIP, streaming, gaming, HTTP/3 (QUIC) |
| Headers मध्येही फरक दिसतो—TCP मध्ये अधिक control information असते: |
TCP connection-oriented आहे. तो byte stream योग्य क्रमाने देण्यासाठी retransmission आणि acknowledgements वापरतो. पण network कायम तुटलं तर delivery ची अमर्याद हमी देऊ शकत नाही; connection error येऊ शकतो. TCP चं minimum header 20 bytes असतं.
UDP connectionless आहे. त्याचं header 8 bytes असतं; UDP स्वतः retransmission किंवा ordering देत नाही. कमी protocol overhead उपयोगी पडू शकतो, पण UDP नेहमीच TCP पेक्षा fast असेल असा नियम नाही. Application स्वतः reliability जोडू शकतं—QUIC/HTTP/3 हे महत्त्वाचं उदाहरण.
HTTP/1.1, HTTP/2, SSH, email आणि अनेक databases TCP वापरतात. DNS, DHCP, VoIP, gaming आणि काही streaming applications UDP वापरतात; exact transport configuration वर अवलंबून असतो.
Headers मध्ये काय वेगळं?
| Header field | TCP | UDP |
|---|---|---|
| Source / destination port | हो | हो |
| Sequence and acknowledgement numbers | हो | नाही |
| Flags (SYN, ACK, FIN, RST, PSH, URG) | हो | नाही |
| Window size (flow control) | हो | नाही |
| Checksum | हो | हो (IPv4 मध्ये optional) |
दोन्हीत source/destination ports आणि checksum असतात. TCP मध्ये sequence/acknowledgement numbers, flags आणि flow control window असते. UDP मध्ये ही fields नसतात. IPv4 UDP checksum optional असू शकतो; यावरून integrity/security ची पूर्ण हमी मिळत नाही.
sudo ss -tn # established TCP connections
sudo ss -un # UDP sockets
dig example.com # DNS query – normally over UDP 53
ss -tn TCP connections दाखवतो, ss -un UDP sockets दाखवतो. dig चा साधा DNS query बहुतेक वेळा UDP 53 वर जातो.
Security मध्ये फरक
TCP handshake च्या half-open states चा SYN flood मध्ये गैरवापर होतो. UDP मध्ये connection handshake नसल्याने forged source addresses वापरून reflection/amplification attacks होऊ शकतात. Open DNS, NTP किंवा memcached services अशा गैरवापरात सहभागी होऊ शकतात.
TCP port चे replies तुलनेने स्पष्ट असतात. UDP scan मध्ये reply न मिळाल्यावर service open आहे की packet filter झाला, हे ठरवणं अवघड असू शकतं. त्यामुळे admins नी UDP services सुद्धा inventory मध्ये तपासाव्यात. Source मधील nmap -sU हा UDP scan option आहे; scan आपल्या authorized lab वरच करा.
Practice
HTTP, SSH, DNS, DHCP, SNMP, MySQL, RDP, NTP, SMTP आणि TFTP यांसाठी TCP, UDP की दोन्ही ते लिहा. मग live video call आणि online game जोडा. प्रत्येक choice मागचं एक कारण लिहा; versions/configuration नुसार बदल होतात का तेही नोंदवा.