close
Pumunta sa nilalaman

TCP

Mula sa Wikipedia, ang malayang ensiklopedya
Transmission Control Protocol
Istak ng protokol
DaglatTCP
(Mga) GumawaVint Cerf at Bob Kahn
Pagpapakilala1974; 52 taon ang nakalipas (1974)
Batay saTransmission Control Program
OSI layerTransport layer (4)
Numero ng IP6
(Mga) RFC9293

Ang Transmission Control Protocol (TCP) ay isa sa mga pangunahing protokol ng Internet protocol suite. Nagmula ito sa unang pagpapatupad ng network kung saan ito ay nagsilbing katuwang ng Internet Protocol (IP). Dahil dito, ang buong hanay ng mga protokol ay karaniwang tinatawag na TCP/IP. Nagbibigay ang TCP ng maaasahan, maayos ang pagkakasunod-sunod, at nasusuring paghahatid ng isang daloy ng mga okteto (byte) sa pagitan ng mga aplikasyon na tumatakbo sa mga host na nakikipag-ugnayan sa pamamagitan ng isang IP network. Ang mga pangunahing aplikasyon sa internet tulad ng World Wide Web, email, malayuang pamamahala, paglilipat ng file, at streaming media ay umaasa sa TCP, na bahagi ng transport layer ng TCP/IP suite. Ang SSL/TLS ay kadalasang tumatakbo sa ibabaw ng TCP. Sa kasalukuyan, nananatiling isang pangunahing protokol ang TCP para sa karamihan ng komunikasyon sa Internet, na nagsisiguro ng maaasahang paglilipat ng datos sa iba't ibang network.[1]

Ang TCP ay connection-oriented o nakatuon sa koneksyon, ibig sabihin kailangan munang magtatag ng koneksyon ang nagpapadala at tumatanggap batay sa napagkasunduang mga parametro; ginagawa nila ito sa pamamagitan ng isang three-way handshake o tatlong-paraan pakikipagkamay na pamamaraan.[2] Kinakailangang nakikinig (passive open) ang server para sa mga kahilingan ng koneksyon mula sa mga kliyente bago maitatag ang koneksyon. Ang three-way handshake (active open), muling pagpapadala (retransmission), at pagtukoy ng error o kamalian ay nagpapataas ng pagiging maaasahan subalit nagpapahaba ng latency o oras ng pagkaanatala. Ang mga aplikasyon na hindi nangangailangan ng maaasahang daloy ng datos ay maaaring gumamit sa halip ng User Datagram Protocol (UDP), na nagbibigay ng connectionless datagram service o serbisyong datogramong walang koneksyon na inuuna ang oras kaysa sa pagiging maaasahan. Gumagamit ang TCP ng mga mekanismo upang maiwasan ang pagsisikip ng network (network congestion avoidance). Gayunpaman, may mga kahinaan din ang TCP, kabilang ang denial of service (pagtanggi sa serbisyo), connection hijacking (pang-aagaw ng koneksyon), TCP veto (pagbeto ng TCP), at reset attack (pag-atakeng muling pagtatakda).

Makasaysayang pinagmulan

[baguhin | baguhin ang wikitext]

Noong Mayo 1974, inilarawan nina Vint Cerf at Bob Kahn ang isang internetworking protocol para sa pagbabahagi ng mga yaman gamit ang packet switching sa pagitan ng mga node ng network.[3] Nakipagtulungan ang mga may-akda kay Gérard Le Lann upang maisama ang mga konsepto mula sa proyektong Pranses na CYCLADES sa bagong network.[4] Ang espesipikasyon ng nagresultang protokol, ang RFC 675 (Specification of Internet Transmission Control Program), ay isinulat nina Vint Cerf, Yogen Dalal, at Carl Sunshine, at inilathala noong Disyembre 1974.[5]

Ang Transmission Control Program ay nagsama ng parehong mga link na nakatuon sa koneksyon at mga serbisyong datagrama sa pagitan ng mga host. Sa bersyon 4, ang monolitikong Transmission Control Program ay hinati sa isang modular na arkitektura na binubuo ng Transmission Control Protocol (TCP) at Internet Protocol (IP).[6][7]

Nagresulta ito sa isang modelo ng networking na nakilala nang impormal bilang TCP/IP, bagaman pormal itong tinukoy sa iba't ibang paraan gaya ng modelong arkitekturang pang-internet na DoD (modelong DoD, para paikliin) o modelong DARPA.[8][9][10] Nang lumaon, naging bahagi ito ng, at kasingkahulugan ng, Internet Protocol Suite. Patuloy na umuunlad ang TCP, na may mga unti-unting pagbabago at mga pinakamahusay na kasanayan na pormal na nakatala sa mga RFC gaya ng RFC 9293 (2022).[11]

Ang mga sumusunod na dokumento ng Internet Experiment Note (IEN) ay naglalarawan sa TCP sa modernong bersyon nito:[12]

  • IEN #5 Specification of Internet Transmission Control Program TCP Version 2 (Marso 1977)
  • IEN #21 Specification of Internetwork Transmission Control Program TCP Version 3 (Enero 1978)
  • IEN #27 A Proposal for TCP Version 3.1 Header Format (Pebrero 1978)
  • IEN #40Transmission Control Protocol Draft Version 4 (Hunyo 1978)
  • IEN #44 Latest Header Formats (Hunyo 1978)
  • IEN #55 Specification of Internetwork Transmission Control Protocol Version 4 (Setyembre 1978)
  • IIEN #81 Transmission Control Protocol Version 4 (Pebrero 1979)
  • EN #112 Transmission Control Protocol (Agosto 1979)
  • EN #124 DOD STANDARD TRANSMISSION CONTROL PROTOCOL (Disyembre 1979)

Ang TCP ay nasapamantayan noong Enero 1980 bilang RFC 761. Noong 2004, tinanggap nina Vint Cerf at Bob Kahn ang Gawad Turing para sa kanilang pundasyonal na gawa sa TCP/IP.[13][14]

Gampanin sa network

[baguhin | baguhin ang wikitext]

Ang Transmission Control Protocol ay nagbibigay ng serbisyong pangkomunikasyon sa isang antas na nasa pagitan ng isang programang aplikasyon at ng Internet Protocol. Nagbibigay ito konektibidad na host-to-host sa transport layer ng modelong internet. Hindi na kailangang malaman ng isang aplikasyon ang mga partikular na mekanismo para sa pagpapadala ng datos sa pamamagitan ng isang link patungo sa isa pang host, gaya ng kinakailangang IP fragmentation upang umangkop sa transmisyong yunit na pinakamataas ng midyum ng transmisyon. Sa transport layer, pinangangasiwaan ng TCP ang lahat ng detalye ng handshaking at transmisyon, at nagpapakita ng isang abstraksyon ng koneksyon sa network sa aplikasyon, na karaniwang idinadaan sa isang network socket interface.

Sa mas mababang antas ng protocol stack, dahil sa pagsisikip ng network, traffic load balancing, o hindi mapaghulaang gawi ng network, ang mga IP packet ay maaaring mawala, madoble, o maipadala nang hindi sunod-sunod. Natutukoy ng TCP ang mga problemang ito, humihiling ng muling pagpapadala ng nawalang datos, muling inaayos ang mga datos na hindi sunod-sunod, at tumutulong pa na bawasan ang pagsisikip ng network upang mapababa ang pagkakataon ng iba pang mga problema. Kung ang datos ay hindi pa rin maipadala, inaabisuhan ang pinagmulan tungkol sa pagkabigong ito. Kapag muling nabuo ng TCP receiver ang pagkakasunod-sunod ng mga octet na orihinal na ipinadala, ipapasa nito ang mga ito sa tumatanggap na aplikasyon. Sa gayon, inihihiwalay ng TCP ang komunikasyon ng aplikasyon mula sa mga detalye ng pinagbabatayang networking.

Ang TCP ay na-optimisa para sa tumpak na pagpapadala sa halip na mabilis na pagpapadala, at maaaring magkaroon ng medyo matagal na pagkaantala (umaabot ng ilang segundo) habang naghihintay para sa mga mensaheng hindi sunod-sunod o muling pagpapadala ng mga nawalang mensahe. Samakatuwid, hindi ito partikular na angkop para sa mga real-time application gaya ng Voice over IP (VoIP). Para sa mga naturang aplikasyon, ang mga protocol gaya ng Real-time Transport Protocol (RTP) na gumagana sa ibabaw ng User Datagram Protocol (UDP) ang karaniwang inirerekomenda.[15]

Ang TCP ay isang maaasahang serbisyo sa paghahatid ng byte stream na tinitiyak na ang lahat ng mga byte na natanggap ay magiging katulad at nasa parehong pagkakasunod-sunod ng mga ipinadala. Dahil ang paglilipat ng packet sa maraming network ay hindi maaasahan, nakakamit ito ng TCP gamit ang isang teknik na kilala bilang positibong pagkilala na may muling pagpapadala . Nangangailangan ito sa tumatanggap na tumugon gamit ang isang mensahe ng pagkilala habang tinatanggap nito ang datos. Ang nagpapadala ay nagtatago ng talaan ng bawat packet na ipinadala nito at nagpapanatili ng isang tagapag-oras mula nang ipadala ang packet. Muling ipapadala ng nagpapadala ang isang packet kung mapaso ang tagapag-oras bago matanggap ang pagkilala. Ang tagapag-oras ay kailangan sakaling mawala o masira ang packet.[15]

Habang ang IP ang nangangasiwa sa aktuwal na paghahatid ng datos, sinusubaybayan naman ng TCP ang mga segment – ang mga indibidwal na yunit ng transmisyon ng datos kung saan hinahati ang isang mensahe para sa mahusay na routing sa network. Halimbawa, kapag ang isang HTML file ay ipinadala mula sa isang web server, hinahati ng TCP software layer ng server ang file sa mga segment at ipinapasa ang mga ito nang paisa-isa sa internet layer sa network stack. Ang internet layer software ay binabalot ang bawat TCP segment sa isang IP packet sa pamamagitan ng pagdaragdag ng isang header na may kasamang destinasyong IP address. Kapag natanggap na ang mga ito ng client program ng destinasyong computer, ang TCP software sa transport layer ay muling bubuuin ang mga segment at titiyakin na ang mga ito ay tama ang pagkakasunod-sunod at walang mali habang inihahatid ang nilalaman ng file sa tumatanggap na aplikasyon.

Estruktura ng segment ng TCP

[baguhin | baguhin ang wikitext]

Ang TCP ay tumatanggap ng datos mula sa isang istrim ng datos, hinahati ito sa mga piraso (chunks), at nagdaragdag ng isang TCP header upang makabuo ng isang TCP segment. Ang segment na ito ay binabalot sa isang datagrama ng IP at ipinagpapalit sa mga peer.[16]

Sa tumpak na terminolohiya, ang segment ay tumutukoy sa protocol data unit (PDU) ng TCP, ang datagrama[17] sa IP PDU, at ang frame sa data link layer PDU:

Processes transmit data by calling on the TCP and passing buffers of data as arguments. The TCP packages the data from these buffers into segments and calls on the internet module [e.g. IP] to transmit each segment to the destination TCP.[18] (Ang mga proseso ay naglilipat ng datos sa pamamagitan ng pagtawag sa TCP at pagpasa ng mga buffer ng datos bilang mga argumento. Binabalot ng TCP ang datos mula sa mga buffer na ito upang maging mga segment, at tatawagin ang internet module (halimbawa, ang IP) upang ipadala ang bawat segment patungo sa destinasyong TCP.)

Ang isang TCP segment ay binubuo ng isang segment header at isang seksyon ng datos. Ang segment header ay naglalaman ng 10 mandatoryong field, at isang opsyonal na extension field (Options). Ang seksyon ng datos ay sumusunod sa header at ito ang payload data na dala para sa aplikasyon.[19]

Pormat ng TCP header[19]
Offset Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Source Port Destination Port
4 32 Sequence Number
8 64 Acknowledgement Number (may saysay kapag may ACK bit)
12 96 Data Offset Reserved
CWR
ECE
URG
ACK
PSH
RST
SYN
FIN
Window
16 128 Checksum Urgent Pointer (may saysay kapag mayroong URG bit)[20]
20 160 (Options) Kung mayroon, ang Data Offset ay higit sa 5.
Naka-pad na may mga sero sa isang maraming 32 bit, yayamang bumibilang ang Data Offset ng mga word ng 4 na octet.
56 448
60 480 Data
64 512

Mga field ng segment header

[baguhin | baguhin ang wikitext]
Field Laki Paglalarawan
Source Port 16 na bit Tinutukoy ang port ng nagpapadala.
Destination Port 16 na bit Tinutukoy ang port ng tumatanggap.
Sequence Number 32 bit (1) Kung ang SYN=1, ito ang initial sequence number. (2) Kung SYN=0, ito ang naipong bilang ng unang byte sa kasalukuyang session.
Acknowledgement Number 32 bit Kung ang ACK flag ay naka-set, ang halaga ng field na ito ay ang susunod na sequence number na inaasahan ng nagpapadala ng ACK. Kinikilala nito ang pagtanggap ng lahat ng mga naunang byte (kung mayroon man).[21] Ang unang ACK na ipinapadala ng bawat panig ay kinikilala ang mismong initial sequence number ng kabilang panig, subalit wala pang kasamang datos.[22]
Data Offset 4 na bit Sukat ng TCP header (pinakamaliit na 20 byte, pinakamataas na 60 byte).
Reserved 4 na bit Para sa hinaharap na paggamit at dapat na itakda sa sero; hindi dapat itakda ng mga nagpapadala ang mga ito at dapat balewalain ng mga tumatanggap kung may nakatakda man, sa kawalan ng karagdagang detalye at implementasyon.

Mula 2003 hanggang 2017, ang huling bit (bit 103 ng header) ay tinukoy bilang NS (Nonce Sum) flag ng eksperimental na (ECN-nonce).RFC 3540 () Hindi kailanman nagkaroon ng malawakang paggamit ang ECN-nonce at ang RFC na ito ay inilipat na sa katayuang Historic.[23]

Isang balangkas ng RFC[24] ang nagpapanukala ng bagong gamit para sa bit na ito. Ang bit ay ginagamit na ngayon para sa pakikipag-negosasyon sa paggamit ng Accurate ECN.

Flags 8 bit Mga kontrol na bit: CWR, ECE, URG, ACK, PSH, RST, SYN, FIN.
Window 16 na bit Dami ng datos na handang tanggapin ng tatanggap o receiver.
Checksum 16 na bit Pagsusuri ng mali (error-checking) para sa integridad ng datos
Urgent Pointer 16 na bit Ginagamit kung ang URG flag ay naka-set para sa apurahang datos.
Options (TCP Option) Nagbabago ang haba, hanggang 40 byte (320 bit); Haba ng mga option (byte) = (Data Offset − 5) × 4; katumbas na bit formula ayon sa RFC 9293: (Data Offset − 5) × 32. Ang haba ng field na ito ay itinatakda ng field na Data Offset. Ang padding ng TCP header ay ginagamit upang matiyak na ang TCP header ay nagtatapos, at ang datos ay nagsisimula, sa isang 32-bit na hangganan. Ang padding ay binubuo ng mga sero.

Ang mga opsyon ay may hanggang tatlong field: Option-Kind (1 byte), Option-Length (1 byte), at Option-Data (nagbabago). Ang field na Option-Kind ay nagpapahiwatig ng uri ng opsyon at ito lamang ang field na hindi opsyonal. Depende sa halaga ng Option-Kind, ang susunod na dalawang field ay maaaring itakda. Ang Option-Length ay nagpapahiwatig ng kabuuang haba ng opsyon, at ang Option-Data ay naglalaman ng datos na nauugnay sa opsyon, kung naaangkop. Halimbawa, ang isang Option-Kind byte na 1 ay nagpapahiwatig na ito ay isang "walang operasyon" na opsyon na ginagamit lamang para sa padding, at walang mga field ng Option-Length o Option-Data na kasunod nito. Ang isang Option-Kind byte na 0 ay nagmamarka ng dulo ng mga opsyon, at ito rin ay isang byte lamang. Ang isang Option-Kind byte na 2 ay ginagamit upang ipahiwatig ang opsyong Maximum Segment Size, at susundan ito ng isang Option-Length byte na tumutukoy sa haba ng MSS field. Ang Option-Length ay ang kabuuang haba ng ibinigay na field ng mga opsyon, kasama ang mga field ng Option-Kind at Option-Length. Kaya habang ang halaga ng MSS ay karaniwang ipinapahayag sa dalawang byte, ang Option-Length ay magiging 4. Bilang halimbawa, ang isang MSS option field na may halagang 0x05B4 ay nakakodigo bilang (0x02 0x04 0x05B4) sa seksyon ng mga opsyon ng TCP.

Ang ilang mga opsyon ay maaari lamang ipadala kapag ang SYN ay naka-set; ang mga ito ay ipinapahiwatig sa bilang [SYN] sa sumunod na talahanayan. Ang Option-Kind at mga karaniwang haba ay ibinibigay bilang (Option-Kind, Option-Length).

Data Nagbabago Ang payload ng TCP packet.
Option-Kind Option-Length Option-Data Layunin Mga pananda
0 Dulo ng listahan ng mga option Ginagamit upang markahan ang pagtatapos ng options field.
1 Walang operasyon Maaaring gamitin upang itugma ang mga option field sa mga hangganan ng 32-bit para sa mas mabilis na pagproseso.
2 4 SS Pinakamalaking laki ng segment [SYN] Tinutukoy ang pinakamalaking laki ng segment na kayang tanggapin.
3 3 S Window scale [SYN] Pinapalaki ang epektibong laki ng tatanggap na window lampas sa 64 KB.[25]
4 2 Pinahihintulutan ang Selective Acknowledgement [SYN] Nagpapahiwatig na ang host ay may kakayahang gumamit ng SACK.[26]
5 N (10, 18, 26, o 34) BBBB, EEEE,... Selective ACKnowledgement (SACK) Ang unang dalawang byte ay sinusundan ng listahan ng 1–4 na mga block na kinikilala (ACK), gamit ang mga 32-bit begin/end pointer.
8 10 TTTT, EEEE Timestamp at echo ng nakaraan Ginagamit para sa pagkalkula ng Round Trip Time (RTT) at proteksyon laban sa mga lumang segment.[25]
28 4 Option para sa User Timeout Tinutukoy kung gaano katagal maghihintay ang TCP bago ituring na bigo ang koneksyon.
29 N Option para sa TCP Authentication (TCP-AO) Para sa pagpapatunay ng mensahe; pumapalit sa MD5 authentication (option 19) na idinisenyo para sa BGP mga session.[27]
30 N Multipath TCP (MPTCP) Pinapayagan ang isang koneksyong TCP na gumamit ng maraming network path nang sabay-sabay.

Ang TCP ay maaaring atakehin sa iba't ibang paraan. Ang pagsusuri sa mga resulta ng TCP, kasama ang mga posibleng solusyon (mitigations) para sa mga natukoy na isyu, ay nailathala noong 2009[28] at ipinagpatuloy sa loob ng IETF hanggang 2012.[29] Ang mga tanyag na kahinaan ay kinabibilangan ng denial of service (DoS), connection hijacking, TCP veto, at TCP reset attack.

Mga port ng TCP

[baguhin | baguhin ang wikitext]

Ang isang koneksyon sa TCP ay kinikilala sa pamamagitan ng isang apat-na-tupla: source address, source port, destination address, at destination port.[a][30][31] Ginagamit ang mga port number upang tukuyin ang iba't ibang serbisyo at payagan ang maraming koneksyon sa pagitan ng mga host. Gumagamit ang TCP ng 16-bit na mga port number, na nagbibigay ng 65,536 na posibleng halaga para sa bawat isa sa mga source at destination port.[19]

Dahil ang pagkakakilanlan ng koneksyon ay nakadepende sa mga address, ang mga koneksyon sa TCP ay nakatali lamang sa iisang landas ng network (single network path). Hindi maaaring gumamit ang TCP ng ibang ruta na available sa mga multihomed host, at napuputol ang mga koneksyon kung magbabago ang address ng isang end-point.[32]

Ang mga numero ng port ay hinahati sa tatlong pangunahing kategorya:

  • Mga kilalang port (0–1023): Itinalaga ng Internet Assigned Numbers Authority (IANA) at karaniwang ginagamit ng mga proseso sa antas ng sistema (system-level processes). Halimbawa: FTP (20 at 21), SSH (22), TELNET (23), SMTP (25), HTTP (80), at HTTPS/SSL (443).
  • Nakarehistrong port (1024–49151): Maaaring italaga sa mga partikular na serbisyo ng mga third-party developer, ngunit ginagamit din ng ilang operating system bilang mga ephemeral client port.
  • Dinamiko o pribadong mga port (49152–65535): Hindi nauugnay sa anumang rehistradong serbisyo at karaniwang ginagamit lamang bilang mga ephemeral port para sa mga pansamantalang koneksyon ng client.

Ang Network Address Translation (NAT) ay karaniwang gumagamit ng mga dynamic port number sa bahaging nakaharap sa publiko (public-facing side) upang pagbukod-bukurin ang daloy ng trapiko. Nagbibigay-daan ito upang ang maraming IP address sa loob ng isang pribadong subnetwork ay mapagsilbihan ng iisang pampublikong address lamang.

  1. Sa madaling salita, ito ay isang pares ng mga network socket para sa pinagmulan (source) at destinasyon, kung saan ang bawat isa ay binubuo ng isang address at isang port.

Mga sanggunian

[baguhin | baguhin ang wikitext]
  1. Comer, D. E. (2021). Internetworking with TCP/IP (sa wikang Ingles) (ika-6 (na) labas). Pearson.
  2. Labrador, Miguel A.; Perez, Alfredo J.; Wightman, Pedro M. (2010). Location-Based Information Systems Developing Real-Time Tracking Applications (sa wikang Ingles). CRC Press. ISBN 9781000556803.
  3. Vinton G. Cerf; Robert E. Kahn (May 1974). "A Protocol for Packet Network Intercommunication" (PDF). IEEE Transactions on Communications (sa wikang Ingles). 22 (5): 637–648. Bibcode:1974ITCom..22..637C. doi:10.1109/tcom.1974.1092259. Inarkibo mula sa orihinal (PDF) noong March 4, 2016.
  4. Bennett, Richard (Setyembre 2009). "Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate" (PDF) (sa wikang Ingles). Information Technology and Innovation Foundation. p. 11. Inarkibo (PDF) mula sa orihinal noong 29 Agosto 2019. Nakuha noong 11 Setyembre 2017.
  5. RFC 675.
  6. Russell, Andrew Lawrence (2008). 'Industrial Legislatures': Consensus Standardization in the Second and Third Industrial Revolutions (Tesis). " Tingnan ang Abbate, Inventing the Internet, 129–30; Vinton G. Cerf (Oktubre 1980). "Protocols for Interconnected Packet Networks". ACM SIGCOMM Computer Communication Review (sa wikang Ingles). 10 (4): 10–11.; at RFC 760. IETF. doi:10.17487/RFC0760."
  7. Postel, Jon (15 Agosto 1977), Comments on Internet Protocol and TCP (sa wikang Ingles), IEN 2, inarkibo mula sa orihinal noong Mayo 16, 2019, nakuha noong Hunyo 11, 2016, We are screwing up in our design of internet protocols by violating the principle of layering. Specifically we are trying to use TCP to do two things: serve as a host level end to end protocol, and to serve as an internet packaging and routing protocol. These two things should be provided in a layered and modular way.
  8. Cerf, Vinton G. (1 Abril 1980). "Final Report of the Stanford University TCP Project" (sa wikang Ingles).
  9. Cerf, Vinton G; Cain, Edward (Oktubre 1983). "The DoD internet architecture model". Computer Networks (sa wikang Ingles). 7 (5): 307–318. doi:10.1016/0376-5075(83)90042-9.
  10. "The TCP/IP Guide – TCP/IP Architecture and the TCP/IP Model". www.tcpipguide.com (sa wikang Ingles). Nakuha noong 2020-02-11.
  11. Eddy, Wesley (Agosto 2022). Transmission Control Protocol (TCP) (sa wikang Ingles). IETF. doi:10.17487/RFC9293. RFC 9293.
  12. "Internet Experiment Note Index". www.rfc-editor.org (sa wikang Ingles). Nakuha noong 2024-01-21.
  13. "Robert E Kahn – A.M. Turing Award Laureate". amturing.acm.org (sa wikang Ingles). Inarkibo mula sa orihinal noong 2019-07-13. Nakuha noong 2019-07-13.
  14. "Vinton Cerf – A.M. Turing Award Laureate". amturing.acm.org (sa wikang Ingles). Inarkibo mula sa orihinal noong 2021-10-11. Nakuha noong 2019-07-13.
  15. 1 2 Comer, Douglas E. (2006). Internetworking with TCP/IP: Principles, Protocols, and Architecture (sa wikang Ingles). Bol. 1 (ika-5 (na) labas). Prentice Hall. ISBN 978-0-13-187671-2.
  16. RFC 9293, 2.2. Key TCP Concepts.
  17. RFC 791, pp. 5–6.
  18. RFC 9293.
  19. 1 2 3 RFC 9293, 3.1. Header Format.
  20. RFC 9293, 3.8.5 The Communication of Urgent Information.
  21. RFC 9293, 3.4. Sequence Numbers.
  22. RFC 9293, 3.4.1. Initial Sequence Number Selection.
  23. "Change RFC 3540 "Robust Explicit Congestion Notification (ECN) Signaling with Nonces" to Historic". datatracker.ietf.org (sa wikang Ingles). Nakuha noong 2023-04-18.
  24. Briscoe, Bob; Kühlewind, Mirja; Scheffenegger, Richard (10 Marso 2025). More Accurate Explicit Congestion Notification (AccECN) Feedback in TCP (sa wikang Ingles). IETF. I-D draft-ietf-tcpm-accurate-ecn. Nakuha noong 2025-10-24.
  25. 1 2 RFC 7323.
  26. RFC 2018, 2. Sack-Permitted Option.
  27. Heffernan, Andy (Agosto 1998). Protection of BGP Sessions via the TCP MD5 Signature Option (sa wikang Ingles). IETF. doi:10.17487/RFC2385. RFC 2385. Nakuha noong 2023-12-30.
  28. "Security Assessment of the Transmission Control Protocol (TCP)" (PDF) (sa wikang Ingles). Inarkibo mula sa orihinal (PDF) noong Marso 6, 2009. Nakuha noong 2010-12-23.
  29. Survey of Security Hardening Methods for Transmission Control Protocol (TCP) Implementations. IETF. I-D draft-ietf-tcpm-tcp-security.
  30. RFC 9293, 4. Glossary.
  31. RFC 8095, p. 6.
  32. Paasch & Bonaventure 2014, p. 51.