TCP

İletim Kontrol Protokolü (TCP), İnternet protokol paketinin ana protokollerinden biridir. İnternet Protokolünü (IP) tamamladığı ilk ağ uygulamasında ortaya çıkmıştır. Bu nedenle, tüm paket genellikle TCP/IP olarak adlandırılır. TCP, bir IP ağı üzerinden iletişim kuran ana bilgisayarlarda çalışan uygulamalar arasında bir oktet (bayt) akışının güvenilir, sıralı ve hata kontrollü teslimatını sağlar. World Wide Web, e-posta, uzaktan yönetim ve dosya aktarımı gibi başlıca internet uygulamaları, TCP/IP paketinin Taşıma Katmanının bir parçası olan TCP'ye dayanır. SSL/TLS genellikle TCP'nin üzerinde çalışır. ⓘ

TCP bağlantı odaklıdır ve veri gönderilmeden önce istemci ile sunucu arasında bir bağlantı kurulur. Bir bağlantı kurulmadan önce sunucunun istemcilerden gelen bağlantı isteklerini dinliyor (pasif açık) olması gerekir. Üç yönlü el sıkışma (aktif açık), yeniden iletim ve hata tespiti güvenilirliği artırır ancak gecikme süresini uzatır. Güvenilir veri akışı hizmeti gerektirmeyen uygulamalar, güvenilirlik yerine zamana öncelik veren bağlantısız bir datagram hizmeti sağlayan Kullanıcı Datagram Protokolü'nü (UDP) kullanabilir. TCP ağ tıkanıklığını önleme özelliğini kullanır. Bununla birlikte, TCP'nin hizmet reddi, bağlantı kaçırma, TCP vetosu ve sıfırlama saldırısı gibi güvenlik açıkları vardır. ⓘ

Gelişmiş bilgisayar ağlarında paket anahtarlamalı bilgisayar iletişiminde kayıpsız veri gönderimi sağlayabilmek için TCP protokolü yazılmıştır. HTTP, HTTPS, POP3, SSH, SMTP, Telnet ve FTP gibi internet'in kullanıcı açısından en popüler protokollerinin veri iletimi TCP vasıtasıyla yapılır. ⓘ

Tarihçe

İlk olarak 1974 Mayıs ayında Elektrik ve Elektronik Mühendisleri Enstitüsü (IEEE) tarafından “A Protocol for Packet Network Intercommunication” başlıklı bir makale yayınlandı. Makalenin yazarları bu yazıda; Vint Cerf ve Bob Khan bir ağ üzerinde yer alan uçlar (nodes) arasında kaynak paylaşımını sağlamak amacıyla "packet-switching" yöntemini kullanan bir ağ protokolü tanımladılar. Bu protokol modelini paket anahtarlamalı olarak nitelendirdiler ve TCP‘nin temelleri atılmış oldu. ⓘ

TCP/IP ilk olarak Amerika Savunma Bakanlığı'nın (DoD) veri iletişimi ihtiyacını karşılamak amacıyla tasarlanmıştır. 1960'lı yılların sonunda Amerika Savunma Bakanlığı'na bağlı olarak çalışan Advanced Research Projects Agency (ARPA), ABD'de bulunan üniversitelerle, ağ üzerinden veri alışverişinde bulunmak amacıyla, üretici markasından bağımsız bir protokol bulmak amacıyla çalışmaya başladı. Katılımcılar bu çalışmalar sonucunda ARPANET'i kurdular. ARPANET internet tarihindeki ilk paket-anahtarlamalı (packet-switching) ağ oldu. ARPANET ilk olarak 1969 yılının sonlarında dört adet uçla (node) çalışmaya başladı. Bu çalışmanın başarılı olmasının sonucunda "ARPA Internet (ARPANET)" adındaki ilk geniş alan ağı kurulmuş oldu. ⓘ

Mayıs 1974'te Vint Cerf ve Bob Kahn, ağ düğümleri arasında paket anahtarlama kullanarak kaynakları paylaşmak için bir internetworking protokolü tanımladılar. Yazarlar, Fransız CYCLADES projesindeki kavramları yeni ağa dahil etmek için Gérard Le Lann ile birlikte çalışıyorlardı. Ortaya çıkan protokolün spesifikasyonu, RFC 675 (İnternet İletim Kontrol Programının Spesifikasyonu), Vint Cerf, Yogen Dalal ve Carl Sunshine tarafından yazıldı ve Aralık 1974'te yayınlandı. Bu belge, internetwork'ün kısaltması olarak internet teriminin ilk kullanımını içermektedir. ⓘ

Bu modelin merkezi kontrol bileşeni, ana bilgisayarlar arasında hem bağlantı odaklı bağlantıları hem de datagram hizmetlerini içeren İletim Kontrol Programıydı. Monolitik İletim Kontrol Programı daha sonra İletim Kontrol Protokolü ve İnternet Protokolünden oluşan modüler bir mimariye bölündü. Bu, resmi olarak Savunma Bakanlığı (DOD) modeli, ARPANET modeli ve nihayetinde İnternet Protokol Paketi olarak adlandırılsa da gayri resmi olarak TCP/IP olarak bilinen bir ağ modeliyle sonuçlandı. ⓘ

Vint Cerf ve Bob Kahn, TCP/IP üzerindeki temel çalışmaları nedeniyle 2004 yılında Turing Ödülü'nü aldılar. ⓘ

Ağ işlevi

İletim Kontrol Protokolü, bir uygulama programı ile İnternet Protokolü arasında ara düzeyde bir iletişim hizmeti sağlar. İnternet modelinin taşıma katmanında ana bilgisayardan ana bilgisayara bağlantı sağlar. Bir uygulamanın, iletim ortamının maksimum iletim birimini karşılamak için gerekli IP parçalanması gibi bir bağlantı üzerinden başka bir ana bilgisayara veri göndermek için belirli mekanizmaları bilmesi gerekmez. Aktarım katmanında, TCP tüm el sıkışma ve iletim ayrıntılarını ele alır ve tipik olarak bir ağ soketi arayüzü aracılığıyla uygulamaya ağ bağlantısının bir soyutlamasını sunar. ⓘ

Protokol yığınının alt seviyelerinde, ağ tıkanıklığı, trafik yükü dengeleme veya öngörülemeyen ağ davranışı nedeniyle IP paketleri kaybolabilir, çoğaltılabilir veya sıra dışı teslim edilebilir. TCP bu sorunları tespit eder, kayıp verilerin yeniden iletilmesini talep eder, sırasız verileri yeniden düzenler ve hatta diğer sorunların ortaya çıkmasını azaltmak için ağ tıkanıklığını en aza indirmeye yardımcı olur. Veriler hala teslim edilmemişse, kaynak bu başarısızlıktan haberdar edilir. TCP alıcısı orijinal olarak iletilen sekizli dizisini yeniden bir araya getirdikten sonra bunları alıcı uygulamaya iletir. Böylece TCP, uygulamanın iletişimini altta yatan ağ ayrıntılarından soyutlar. ⓘ

TCP, World Wide Web (WWW), e-posta, Dosya Aktarım Protokolü, Güvenli Kabuk, eşler arası dosya paylaşımı ve medya akışı dahil olmak üzere birçok internet uygulaması tarafından yaygın olarak kullanılmaktadır. ⓘ

TCP zamanında teslimattan ziyade doğru teslimat için optimize edilmiştir ve sıra dışı mesajları veya kayıp mesajların yeniden iletimini beklerken nispeten uzun gecikmelere (saniye mertebesinde) neden olabilir. Bu nedenle, IP üzerinden ses gibi gerçek zamanlı uygulamalar için özellikle uygun değildir. Bu tür uygulamalar için genellikle Kullanıcı Datagram Protokolü (UDP) üzerinden çalışan Gerçek Zamanlı Aktarım Protokolü (RTP) gibi protokoller tavsiye edilir. ⓘ

TCP, alınan tüm baytların gönderilenlerle aynı ve aynı sırada olacağını garanti eden güvenilir bir akış teslim hizmetidir. Birçok ağ tarafından paket aktarımı güvenilir olmadığından, TCP bunu yeniden iletim ile pozitif onay olarak bilinen bir teknik kullanarak başarır. Bu, alıcının verileri aldığında bir onay mesajıyla yanıt vermesini gerektirir. Gönderici, gönderdiği her paketin kaydını tutar ve paketin gönderildiği andan itibaren bir zamanlayıcı tutar. Gönderici, onay mesajını almadan önce zamanlayıcının süresi dolarsa paketi yeniden iletir. Zamanlayıcı, bir paketin kaybolması veya bozulması durumunda gereklidir. ⓘ

IP verilerin gerçek teslimatını gerçekleştirirken, TCP segmentleri takip eder - bir mesajın ağ üzerinden verimli bir şekilde yönlendirilmesi için bölündüğü bireysel veri aktarım birimleri. Örneğin, bir web sunucusundan bir HTML dosyası gönderildiğinde, bu sunucunun TCP yazılım katmanı dosyayı segmentlere böler ve bunları ayrı ayrı ağ yığınındaki internet katmanına iletir. İnternet katmanı yazılımı, (diğer verilerin yanı sıra) hedef IP adresini içeren bir başlık ekleyerek her TCP segmentini bir IP paketine kapsüller. Hedef bilgisayardaki istemci program bunları aldığında, aktarım katmanındaki TCP yazılımı segmentleri yeniden birleştirir ve dosya içeriğini alıcı uygulamaya aktarırken bunların doğru sıralanmasını ve hatasız olmasını sağlar. ⓘ

TCP segment yapısı

İletim Kontrol Protokolü bir veri akışından verileri kabul eder, parçalara böler ve bir TCP segmenti oluşturan bir TCP başlığı ekler. TCP segmenti daha sonra bir İnternet Protokolü (IP) datagramına kapsüllenir ve eşler arasında değiş tokuş edilir. ⓘ

TCP paketi terimi hem gayri resmi hem de resmi kullanımda ortaya çıkarken, daha kesin terminolojide segment TCP protokol veri birimini (PDU), datagram IP PDU'sunu ve çerçeve veri bağlantı katmanı PDU'sunu ifade eder:

Süreçler TCP'yi çağırarak ve veri tamponlarını argüman olarak ileterek veri iletir. TCP bu tamponlardaki verileri segmentler halinde paketler ve her segmenti hedef TCP'ye iletmek için internet modülünü [örneğin IP] çağırır. ⓘ

Bir TCP segmenti bir segment başlığı ve bir veri bölümünden oluşur. Segment başlığı 10 zorunlu alan ve isteğe bağlı bir uzantı alanı içerir (Seçenekler, tabloda pembe arka plan). Veri bölümü başlığı takip eder ve uygulama için taşınan yük verisidir. Veri bölümünün uzunluğu segment başlığında belirtilmez; IP başlığında belirtilen toplam IP datagram uzunluğundan segment başlığı ve IP başlığının birleşik uzunluğu çıkarılarak hesaplanabilir. ⓘ

TCP segment başlığı ⓘ

Ofsetler	Oktet	0								1								2								3
Oktet	Bit	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
0	0	Kaynak liman																Hedef bağlantı noktası
4	32	Sıra numarası
8	64	Onay numarası (ACK ayarlanmışsa)
12	96	Veri ofseti				Ayrılmış 0 0 0			NS	CWR	ECE	URG	ACK	PSH	RST	SYN	FIN	Pencere Boyutu
16	128	Checksum																Acil durum işaretçisi (URG ayarlıysa)
20	160	Seçenekler (veri ofseti > 5 ise. Gerekirse sonunda "0" bitleri ile doldurulur)
⋮	⋮
60	480

Kaynak bağlantı noktası (16 bit)

Gönderen bağlantı noktasını tanımlar.

Hedef bağlantı noktası (16 bit)

Alıcı bağlantı noktasını tanımlar.

Sıra numarası (32 bit)

İkili bir rolü vardır:

• SYN bayrağı ayarlanmışsa (1), bu başlangıç sıra numarasıdır. Gerçek ilk veri baytının sıra numarası ve ilgili ACK'deki onaylanan numara bu sıra numarası artı 1'dir.
• SYN bayrağı açıksa (0), bu, geçerli oturum için bu segmentin ilk veri baytının birikmiş sıra numarasıdır.

Onay numarası (32 bit)

ACK bayrağı ayarlanmışsa, bu alanın değeri ACK göndericisinin beklediği bir sonraki sıra numarasıdır. Bu, önceki tüm baytların (varsa) alındığını onaylar. Her bir uç tarafından gönderilen ilk ACK, diğer ucun ilk sıra numarasını onaylar, ancak veri göndermez.

Veri ofseti (4 bit)

TCP başlığının 32 bitlik sözcükler cinsinden boyutunu belirtir. Minimum başlık boyutu 5 kelime ve maksimum 15 kelimedir, böylece minimum boyut 20 bayt ve maksimum 60 bayt olur ve başlıkta 40 bayta kadar seçeneğe izin verir. Bu alan adını, aynı zamanda TCP segmentinin başlangıcından gerçek veriye kadar olan ofset olmasından alır.

Ayrılmış (3 bit)

Gelecekte kullanım içindir ve sıfır olarak ayarlanmalıdır.

Bayraklar (9 bit)

Aşağıdaki gibi 9 adet 1 bitlik bayrak (kontrol biti) içerir:

• NS (1 bit): ECN-nonce - gizleme koruması
• CWR (1 bit): Tıkanıklık penceresi azaltıldı (CWR) bayrağı, gönderen ana bilgisayar tarafından ECE bayrağı ayarlanmış bir TCP segmenti aldığını ve tıkanıklık kontrol mekanizmasında yanıt verdiğini belirtmek için ayarlanır.
• ECE (1 bit): ECN-Echo, SYN bayrağının değerine bağlı olarak ikili bir role sahiptir. Şunu gösterir:

• SYN bayrağı ayarlanmışsa (1), TCP eşinin ECN yeteneğine sahip olduğunu gösterir.
• SYN bayrağı açıksa (0), normal iletim sırasında IP başlığında Tıkanıklık Deneyimi bayrağı ayarlanmış (ECN=11) bir paket alındığını gösterir. Bu, TCP göndericisine ağ tıkanıklığının (veya yaklaşan tıkanıklığın) bir göstergesi olarak hizmet eder.

• URG (1 bit): Acil işaretçi alanının önemli olduğunu gösterir
• ACK (1 bit): Onay alanının anlamlı olduğunu gösterir. İstemci tarafından gönderilen ilk SYN paketinden sonraki tüm paketlerde bu bayrak ayarlanmalıdır.
• PSH (1 bit): İtme işlevi. Tamponlanmış veriyi alıcı uygulamaya itmeyi ister.
• RST (1 bit): Bağlantıyı sıfırlar
• SYN (1 bit): Sıra numaralarını senkronize edin. Yalnızca her iki uçtan gönderilen ilk pakette bu bayrak ayarlanmalıdır. Diğer bazı bayraklar ve alanlar bu bayrağa bağlı olarak anlam değiştirir ve bazıları yalnızca ayarlandığında, diğerleri ise temiz olduğunda geçerlidir.
• FIN (1 bit): Göndericiden gelen son paket

Pencere boyutu (16 bit)

Bu segmentin göndericisinin o anda almaya istekli olduğu pencere boyutu birimlerinin sayısını belirten alma penceresinin boyutu. (Bkz. § Akış kontrolü ve § Pencere ölçeklendirme.)

Sağlama toplamı (16 bit)

16 bitlik sağlama toplamı alanı TCP başlığının, yükünün ve bir IP sözde başlığının hata kontrolü için kullanılır. Sözde başlık, kaynak IP adresi, hedef IP adresi, TCP protokolü için protokol numarası (6) ve TCP başlıklarının ve yükünün uzunluğundan (bayt cinsinden) oluşur.

Acil işaretçi (16 bit)

URG bayrağı ayarlanmışsa, bu 16 bitlik alan son acil veri baytını gösteren sıra numarasından bir ofsettir.

Seçenekler (Değişken 0-320 bit, 32 bitlik birimler halinde)

Bu alanın uzunluğu veri ofset alanı tarafından belirlenir. Seçeneklerin en fazla üç alanı vardır: Option-Kind (1 bayt), Option-Length (1 bayt), Option-Data (değişken). Option-Kind alanı seçeneğin türünü belirtir ve isteğe bağlı olmayan tek alandır. Option-Kind değerine bağlı olarak, sonraki iki alan ayarlanabilir. Option-Length seçeneğin toplam uzunluğunu gösterir ve Option-Data, varsa seçenekle ilişkili verileri içerir. Örneğin, 1'lik bir Option-Kind baytı, bunun yalnızca dolgu için kullanılan bir işlem yok seçeneği olduğunu ve ardından Option-Length veya Option-Data alanlarına sahip olmadığını gösterir. 0'lık bir Option-Kind baytı seçeneklerin sonunu işaret eder ve ayrıca yalnızca bir bayttır. 2'lik bir Option-Kind baytı Maksimum Segment Boyutu seçeneğini belirtmek için kullanılır ve ardından MSS alanının uzunluğunu belirten bir Option-Length baytı gelir. Option-Length, Option-Kind ve Option-Length alanları dahil olmak üzere verilen seçenekler alanının toplam uzunluğudur. Dolayısıyla, MSS değeri tipik olarak iki bayt olarak ifade edilirken, Seçenek-Uzunluğu 4 olacaktır. Örnek olarak, 0x05B4 değerine sahip bir MSS seçenek alanı TCP seçenekleri bölümünde (0x02 0x04 0x05B4) olarak kodlanır.

Bazı seçenekler yalnızca SYN ayarlandığında gönderilebilir; bunlar aşağıda ^[SYN] olarak belirtilmiştir. Option-Kind ve standart uzunlukları (Option-Kind, Option-Length) olarak verilmiştir.

Seçenek Türü	Seçenek-Uzunluğu	Seçenek-Veri	Amaç	Notlar
0	-	-	Seçenek listesinin sonu
1	-	-	İşlem yok	Bu, daha iyi performans için seçenek alanlarını 32 bit sınırlarında hizalamak için kullanılabilir.
2	4	SS	Maksimum segment boyutu	Bkz § Maksimum segment boyutu [SYN]
3	3	S	Pencere ölçeği	Ayrıntılar için § Pencere ölçeklendirme bölümüne bakın [SYN]
4	2	-	Seçici Onaya izin verildi	Ayrıntılar için § Seçici onaylar bölümüne bakın[SYN]
5	N (10, 18, 26 veya 34)	BBBB, EEEE, ...	Selective ACKnowledgement (SACK)	Bu ilk iki baytı, 32 bitlik başlangıç/bitiş işaretçileri olarak belirtilen, seçici olarak onaylanan 1-4 blokluk bir liste izler.
8	10	TTTT, EEEE	Zaman damgası ve önceki zaman damgasının yankısı	Ayrıntılar için § TCP zaman damgaları bölümüne bakın

Geri kalan Option-Kind değerleri tarihsel, eski, deneysel, henüz standartlaştırılmamış veya atanmamış değerlerdir. Seçenek numarası atamaları IANA tarafından sürdürülür.

Dolgu

TCP başlık dolgusu, TCP başlığının 32 bitlik bir sınırda bitmesini ve verilerin başlamasını sağlamak için kullanılır. Dolgu sıfırlardan oluşur. ⓘ

Protokol işlemi

Basitleştirilmiş TCP Durum Diyagramı. ESTABLISHED durumunun içindeki durumları da içeren daha ayrıntılı bir durum diyagramı için TCP EFSM diyagramına bakın. ⓘ

TCP protokol işlemleri üç aşamaya ayrılabilir. Bağlantı kurma, veri aktarımı aşamasına girmeden önce bir bağlantı kuran çok adımlı bir el sıkışma sürecidir. Veri aktarımı tamamlandıktan sonra, bağlantı sonlandırması bağlantıyı kapatır ve tahsis edilen tüm kaynakları serbest bırakır. ⓘ

Bir TCP bağlantısı, iletişim için yerel uç noktayı temsil eden bir kaynak olan İnternet soketi aracılığıyla bir işletim sistemi tarafından yönetilir. Bir TCP bağlantısının ömrü boyunca, yerel uç nokta bir dizi durum değişikliğine uğrar:

TCP soket durumları

Eyalet	Bitiş Noktası	Açıklama ⓘ
DİNLE	Sunucu	Herhangi bir uzak TCP uç noktasından bir bağlantı isteği bekleniyor.
SYN-GÖNDERİLDİ	Müşteri	Bir bağlantı isteği gönderdikten sonra eşleşen bir bağlantı isteğinin beklenmesi.
SYN ALINDI	Sunucu	Bir bağlantı isteğini hem aldıktan hem de gönderdikten sonra bağlantı isteği onayı bekleniyor.
KURULDU	Sunucu ve istemci	Açık bir bağlantı, alınan veriler kullanıcıya teslim edilebilir. Bağlantının veri aktarım aşaması için normal durum.
FIN-WAIT-1	Sunucu ve istemci	Uzak TCP'den bir bağlantı sonlandırma isteği veya daha önce gönderilen bağlantı sonlandırma isteğinin onayı bekleniyor.
FIN-WAIT-2	Sunucu ve istemci	Uzak TCP'den bir bağlantı sonlandırma isteği bekleniyor.
KAPAT-BEKLE	Sunucu ve istemci	Yerel kullanıcıdan bir bağlantı sonlandırma isteği bekleniyor.
KAPATMA	Sunucu ve istemci	Uzak TCP'den bir bağlantı sonlandırma isteği onayı bekleniyor.
SON-ACK	Sunucu ve istemci	Daha önce uzak TCP'ye gönderilen bağlantı sonlandırma isteğinin onayının beklenmesi (bağlantı sonlandırma isteğinin onayını içerir).
TIME-WAIT	Sunucu veya istemci	Bağlantıda kalan tüm paketlerin süresinin dolduğundan emin olmak için yeterli sürenin geçmesini bekler.
KAPALI	Sunucu ve istemci	Hiç bağlantı durumu yok.

TCP'nin çalışma esası üç faz altında incelenebilir: 1) Öncelikle hedefle bir bağlantı gerçekleşir. 2) Bağlantı gerçekleştikten sonra veri transferi yapılır. 3) Veri transferi yapıldıktan sonra da bağlantı sona erdirilir. ⓘ

Bağlantı kurulması

Bir istemci bir sunucuya bağlanmaya çalışmadan önce, sunucunun bağlantılara açmak için bir bağlantı noktasına bağlanması ve o bağlantı noktasını dinlemesi gerekir: buna pasif açık denir. Pasif açık kurulduktan sonra, bir istemci üç yönlü (veya 3 adımlı) el sıkışmayı kullanarak aktif bir açık başlatarak bir bağlantı kurabilir:

1. SYN: Aktif açma, istemcinin sunucuya bir SYN göndermesiyle gerçekleştirilir. İstemci segmentin sıra numarasını rastgele bir A değerine ayarlar.
2. SYN-ACK: Yanıt olarak sunucu bir SYN-ACK ile yanıt verir. Onay numarası, alınan sıra numarasından bir fazlasına, yani A+1'e ayarlanır ve sunucunun paket için seçtiği sıra numarası başka bir rastgele sayı olan B'dir.
3. ACK: Son olarak, istemci sunucuya bir ACK gönderir. Sıra numarası alınan onay değerine, yani A+1'e ayarlanır ve onay numarası alınan sıra numarasından bir fazlasına, yani B+1'e ayarlanır. ⓘ

Adım 1 ve 2, bir yön için sıra numarasını belirler ve onaylar. Adım 2 ve 3 diğer yön için sıra numarasını belirler ve onaylar. Bu adımların tamamlanmasının ardından, hem istemci hem de sunucu onayları almış olur ve tam çift yönlü bir iletişim kurulmuş olur. ⓘ

Bağlantı sonlandırma

Bağlantı sonlandırma ⓘ

Bağlantı sonlandırma aşaması, bağlantının her iki tarafının bağımsız olarak sonlandırıldığı dört yönlü bir el sıkışma kullanır. Bir uç nokta bağlantının kendi yarısını durdurmak istediğinde, diğer ucun bir ACK ile onayladığı bir FIN paketi iletir. Bu nedenle, tipik bir kopma, her TCP uç noktasından bir çift FIN ve ACK segmenti gerektirir. İlk FIN'i gönderen taraf son ACK ile yanıt verdikten sonra, bağlantıyı kapatmadan önce bir zaman aşımı bekler, bu süre zarfında yerel bağlantı noktası yeni bağlantılar için kullanılamaz; bu, önceki bir bağlantıyla ilişkili gecikmiş paketlerin sonraki bir bağlantı sırasında teslim edilmesi durumunda ortaya çıkabilecek olası karışıklığı önler. ⓘ

A ana bilgisayarının FIN gönderdiği ve B ana bilgisayarının FIN & ACK ile yanıt verdiği (iki adımı tek bir adımda birleştirerek) ve A ana bilgisayarının ACK ile yanıt verdiği 3 yönlü bir el sıkışma ile bağlantıyı sonlandırmak da mümkündür. ⓘ

Linux ve HP-UX gibi bazı işletim sistemleri, yarı çift yönlü bir kapatma sırası uygular. Ana bilgisayar bir bağlantıyı aktif olarak kapatırsa ve hala okunmamış gelen veri varsa, FIN yerine RST sinyalini gönderir (alınan tüm verileri kaybeder). Bu, bir TCP uygulamasının bir veri kaybı olduğunun farkında olmasını sağlar. ⓘ

Bir bağlantı yarı açık durumda olabilir, bu durumda bir taraf bağlantıyı sonlandırmış ancak diğer taraf sonlandırmamıştır. Sonlandıran taraf artık bağlantıya herhangi bir veri gönderemez, ancak diğer taraf gönderebilir. Sonlandıran taraf, diğer taraf da sonlandırana kadar verileri okumaya devam etmelidir. ⓘ

Kaynak kullanımı

Çoğu uygulama, bir oturumu çalışan bir işletim sistemi süreciyle eşleştiren bir tabloda bir giriş ayırır. TCP paketleri bir oturum tanımlayıcısı içermediğinden, her iki uç nokta da oturumu istemcinin adresini ve bağlantı noktasını kullanarak tanımlar. Bir paket alındığında, TCP uygulaması hedef süreci bulmak için bu tabloda bir arama yapmalıdır. Tablodaki her bir girdi İletim Kontrol Bloğu veya TCB olarak bilinir. Uç noktalar (IP ve port), bağlantının durumu, değiş tokuş edilen paketler hakkında çalışan veriler ve veri göndermek ve almak için tamponlar hakkında bilgi içerir. ⓘ

Sunucu tarafındaki oturum sayısı yalnızca bellekle sınırlıdır ve yeni bağlantılar geldikçe artabilir, ancak istemci sunucuya ilk SYN'yi göndermeden önce geçici bir bağlantı noktası tahsis etmelidir. Bu bağlantı noktası tüm konuşma boyunca tahsisli kalır ve istemcinin IP adreslerinin her birinden giden bağlantı sayısını etkili bir şekilde sınırlar. Bir uygulama gerekli olmayan bağlantıları düzgün bir şekilde kapatamazsa, istemcinin kaynakları tükenebilir ve diğer uygulamalardan bile yeni TCP bağlantıları kuramaz hale gelebilir. ⓘ

Her iki uç nokta da onaylanmamış paketler ve alınan (ancak okunmamış) veriler için yer ayırmalıdır. ⓘ

Veri aktarımı

İletim Kontrol Protokolü, Kullanıcı Datagram Protokolü ile karşılaştırıldığında birkaç temel özellik bakımından farklılık gösterir:

• Sıralı veri aktarımı: hedef ana bilgisayar segmentleri bir sıra numarasına göre yeniden düzenler
• Kayıp paketlerin yeniden iletimi: onaylanmayan herhangi bir kümülatif akış yeniden iletilir
• Hatasız veri aktarımı: Bozuk paketler kayıp olarak kabul edilir ve yeniden iletilir
• Akış kontrolü: güvenilir teslimatı garanti etmek için bir göndericinin veri aktarma hızını sınırlar. Alıcı, göndericiye ne kadar veri alınabileceği konusunda sürekli olarak ipucu verir. Alıcı ana bilgisayarın arabelleği dolduğunda, bir sonraki onay aktarımı askıya alır ve arabellekteki verilerin işlenmesine izin verir.
• Tıkanıklık kontrolü: kayıp paketler (tıkanıklık nedeniyle olduğu varsayılır) veri iletim hızında bir düşüşü tetikler ⓘ

Güvenilir aktarım

TCP, her veri baytını tanımlamak için bir sıra numarası kullanır. Sıra numarası, her bilgisayardan gönderilen baytların sırasını tanımlar, böylece oluşabilecek herhangi bir sıra dışı teslimattan bağımsız olarak veriler sırayla yeniden yapılandırılabilir. İlk baytın sıra numarası, SYN olarak işaretlenen ilk paket için verici tarafından seçilir. Bu sayı keyfi olabilir ve aslında TCP sıra tahmini saldırılarına karşı savunmak için tahmin edilemez olmalıdır. ⓘ

Onaylar (ACK'lar), göndericiye verilerin belirtilen bayta kadar alındığını bildirmek için veri alıcısı tarafından bir sıra numarası ile gönderilir. ACK'lar verinin uygulamaya teslim edildiği anlamına gelmez, sadece veriyi teslim etmenin artık alıcının sorumluluğunda olduğunu belirtir. ⓘ

Güvenilirlik, göndericinin kayıp verileri tespit etmesi ve yeniden iletmesiyle sağlanır. TCP, kaybı tanımlamak için iki temel teknik kullanır. Yeniden iletim zaman aşımı (RTO) ve yinelenen kümülatif onaylar (DupAcks). ⓘ

Dupack tabanlı yeniden iletim

Bir akıştaki tek bir segment (örneğin 100 numaralı segment) kaybolursa, alıcı bu segment numarasının (100) üzerindeki paketleri onaylayamaz çünkü kümülatif ACK'ler kullanır. Bu nedenle alıcı başka bir veri paketi aldığında 99 numaralı paketi tekrar onaylar. Bu yinelenen onay, paket kaybı için bir sinyal olarak kullanılır. Yani, gönderici üç yinelenen onay alırsa, onaylanmamış son paketi yeniden gönderir. Üç eşiği kullanılır çünkü ağ, yinelenen onaylara neden olan segmentleri yeniden sıralayabilir. Bu eşiğin, yeniden sıralama nedeniyle sahte yeniden iletimleri önlediği gösterilmiştir. Bazı TCP uygulamaları, alınan segmentler hakkında açık geri bildirim sağlamak için seçici onaylar (SACK'ler) kullanır. Bu, TCP'nin doğru segmentleri yeniden iletme becerisini büyük ölçüde geliştirir. ⓘ

Zaman aşımına dayalı yeniden iletim

Bir gönderici bir segment ilettiğinde, onayın varış zamanının muhafazakar bir tahmini ile bir zamanlayıcı başlatır. Zamanlayıcının süresi dolarsa segment yeniden iletilir, yeni zaman aşımı eşiği önceki değerin iki katıdır ve üstel geri alma davranışına neden olur. Tipik olarak, ilk zamanlayıcı değeri ${\text{smoothed RTT}}+\max(G,4\times {\text{RTT variation}})$, nerede $G$ saat ayrıntı düzeyidir. Bu, ortadaki adam hizmet reddi saldırganları gibi hatalı veya kötü niyetli aktörler nedeniyle aşırı iletim trafiğine karşı koruma sağlar. ⓘ

Hata tespiti

Sıra numaraları, alıcıların yinelenen paketleri atmasına ve sıra dışı paketleri düzgün bir şekilde sıralamasına olanak tanır. Onaylar, göndericilerin kayıp paketleri ne zaman yeniden ileteceklerini belirlemelerine olanak tanır. ⓘ

Doğruluğu sağlamak için bir sağlama toplamı alanı eklenir; ayrıntılar için § Sağlama toplamı hesaplama bölümüne bakın. TCP sağlama toplamı modern standartlara göre zayıf bir kontroldür ve normalde katman 2'de, hem TCP hem de IP'nin altında, PPP veya Ethernet çerçevesinde kullanıldığı gibi bir CRC bütünlük kontrolü ile eşleştirilir. Bununla birlikte, CRC korumalı atlamalar arasında paketlere hata eklenmesi yaygındır ve 16 bit TCP sağlama toplamı bunların çoğunu yakalar. ⓘ

Akış kontrolü

TCP, göndericinin TCP alıcısının güvenilir bir şekilde alıp işleyemeyeceği kadar hızlı veri göndermesini önlemek için uçtan uca bir akış kontrol protokolü kullanır. Akış kontrolü için bir mekanizmaya sahip olmak, farklı ağ hızlarına sahip makinelerin iletişim kurduğu bir ortamda çok önemlidir. Örneğin, bir bilgisayar, aldığı verileri yavaş işleyen bir akıllı telefona veri gönderirse, akıllı telefonun bunalmamak için veri akışını düzenleyebilmesi gerekir. ⓘ

TCP bir kayan pencere akış kontrol protokolü kullanır. Her TCP segmentinde alıcı, alma penceresi alanında bağlantı için arabelleğe almak istediği ek olarak alınan veri miktarını (bayt cinsinden) belirtir. Gönderen ana bilgisayar, alıcı ana bilgisayardan bir onay ve alma penceresi güncellemesi beklemeden önce yalnızca bu miktara kadar veri gönderebilir. ⓘ

TCP sıra numaraları ve alma pencereleri bir saat gibi davranır. Alıcı her yeni veri segmenti aldığında ve onayladığında alma penceresi değişir. Sıra numaraları bittiğinde, sıra numarası 0'a geri döner. ⓘ

Bir alıcı 0 pencere boyutu bildirdiğinde, gönderici veri göndermeyi durdurur ve persist zamanlayıcısını başlatır. Kalıcılık zamanlayıcısı, alıcıdan gelen sonraki pencere boyutu güncellemesinin kaybolması ve göndericinin alıcıdan yeni bir pencere boyutu güncellemesi alana kadar daha fazla veri gönderememesi durumunda ortaya çıkabilecek kilitlenme durumundan TCP'yi korumak için kullanılır. Süreklilik zamanlayıcısının süresi dolduğunda, TCP göndericisi küçük bir paket göndererek kurtarma girişiminde bulunur, böylece alıcı yeni pencere boyutunu içeren başka bir onay göndererek yanıt verir. ⓘ

Bir alıcı gelen verileri küçük artışlarla işliyorsa, tekrar tekrar küçük bir alma penceresi bildirebilir. TCP başlığının nispeten büyük ek yükü göz önüne alındığında, bir TCP segmentinde yalnızca birkaç bayt veri göndermek verimsiz olduğundan, bu durum aptal pencere sendromu olarak adlandırılır. ⓘ

Tıkanıklık kontrolü

TCP'nin son ana yönü tıkanıklık kontrolüdür. TCP, yüksek performans elde etmek ve ağ performansının ciddi şekilde düştüğü bir tıkanma durumu olan tıkanıklık çöküşünü önlemek için bir dizi mekanizma kullanır. Bu mekanizmalar ağa giren veri oranını kontrol ederek veri akışını çöküşü tetikleyecek bir oranın altında tutar. Ayrıca akışlar arasında yaklaşık olarak maksimum-min adil bir tahsisat sağlarlar. ⓘ

Gönderilen veriler için onaylar ya da onayların eksikliği, göndericiler tarafından TCP göndericisi ve alıcısı arasındaki ağ koşullarını çıkarmak için kullanılır. Zamanlayıcılarla birlikte, TCP göndericileri ve alıcıları veri akışının davranışını değiştirebilir. Bu daha genel olarak tıkanıklık kontrolü veya tıkanıklıktan kaçınma olarak adlandırılır. ⓘ

TCP'nin modern uygulamaları iç içe geçmiş dört algoritma içerir: yavaş başlatma, tıkanıklıktan kaçınma, hızlı yeniden iletim ve hızlı kurtarma. ⓘ

Buna ek olarak, göndericiler, gönderici ile alıcı arasındaki tahmini gidiş-dönüş süresine (RTT) ve bu gidiş-dönüş süresindeki varyansa dayanan bir yeniden iletim zaman aşımı (RTO) kullanır. Bu zamanlayıcının davranışı RFC 6298'de belirtilmiştir. RTT'nin tahmin edilmesinde incelikler vardır. Örneğin, göndericiler yeniden iletilen paketler için RTT örneklerini hesaplarken dikkatli olmalıdır; genellikle Karn Algoritması veya TCP zaman damgalarını kullanırlar (bkz. RFC 1323). Bu bireysel RTT örneklerinin daha sonra Jacobson algoritması kullanılarak düzeltilmiş bir gidiş-dönüş süresi (SRTT) oluşturmak için zaman içinde ortalaması alınır. Bu SRTT değeri gidiş-dönüş süresi tahmini olarak kullanılır. ⓘ

TCP'yi kayıpları güvenilir bir şekilde ele almak, hataları en aza indirmek, tıkanıklığı yönetmek ve çok yüksek hızlı ortamlarda hızlı gitmek için geliştirmek, devam eden araştırma ve standart geliştirme alanlarıdır. Sonuç olarak, bir dizi TCP tıkanıklık önleme algoritması varyasyonu vardır. ⓘ

Maksimum segment boyutu

Maksimum segment boyutu (MSS), TCP'nin tek bir segmentte almaya istekli olduğu bayt cinsinden belirtilen en büyük veri miktarıdır. En iyi performans için MSS, paket kaybına ve aşırı yeniden iletime yol açabilecek IP parçalanmasını önleyecek kadar küçük ayarlanmalıdır. Bunu başarmak için, tipik olarak MSS, TCP bağlantısı kurulduğunda MSS seçeneği kullanılarak her iki taraf tarafından duyurulur. Seçenek değeri, gönderici ve alıcının doğrudan bağlı olduğu ağların veri bağlantı katmanının maksimum iletim birimi (MTU) boyutundan türetilir. TCP göndericileri, gönderici ve alıcı arasındaki ağ yolu boyunca minimum MTU'yu çıkarmak için yol MTU keşfini kullanabilir ve bunu ağ içinde IP parçalanmasını önlemek için MSS'yi dinamik olarak ayarlamak için kullanabilir. ⓘ

MSS duyurusu MSS anlaşması olarak da adlandırılabilir, ancak bir TCP bağlantısındaki iki veri akışı yönü için MSS'nin tamamen bağımsız iki değerine izin verildiğinden, MSS üzerinde anlaşmaya varılmaz, bu nedenle çift yönlü bir bağlantı için ortak bir MSS yapılandırması üzerinde anlaşmaya gerek yoktur. ⓘ

Seçici onaylar

Sadece orijinal TCP protokolü tarafından kullanılan kümülatif onay şemasına güvenmek, paketler kaybolduğunda verimsizliğe yol açabilir. Örneğin, sıra numarası 1.000 ila 10.999 olan baytların eşit büyüklükteki 10 farklı TCP segmentinde gönderildiğini ve ikinci segmentin (sıra numaraları 2.000 ila 2.999) iletim sırasında kaybolduğunu varsayalım. Saf bir kümülatif onay protokolünde, alıcı yalnızca 2.000'lik bir kümülatif ACK değeri gönderebilir (alınan verinin son sıra numarasından hemen sonraki sıra numarası) ve 3.000 ila 10.999 arasındaki baytları başarıyla aldığını söyleyemez. Bu nedenle gönderici 2.000 sıra numarasıyla başlayan tüm verileri yeniden göndermek zorunda kalabilir. ⓘ

Bu sorunu hafifletmek için TCP, 1996 yılında RFC 2018'de tanımlanan seçici onay (SACK) seçeneğini kullanır; bu, alıcının, temel TCP onayında olduğu gibi, art arda alınan son bitişik baytın son sıra numarasının hemen ardından gelen sıra numarasına ek olarak, doğru şekilde alınan süreksiz paket bloklarını onaylamasına olanak tanır. Onay, her bir SACK bloğunun Bloğun Sol Kenarı (bloğun ilk sıra numarası) ve Bloğun Sağ Kenarı (bloğun son sıra numarasını hemen takip eden sıra numarası) tarafından iletildiği, bir Bloğun alıcının doğru bir şekilde aldığı bitişik bir aralık olduğu bir dizi SACK bloğu belirtebilir. Yukarıdaki örnekte, alıcı kümülatif ACK değeri 2.000 olan bir ACK segmenti ve sıra numaraları 3.000 ve 11.000 olan bir SACK seçenek başlığı gönderecektir. Gönderici buna uygun olarak yalnızca sıra numaraları 2.000 ila 2.999 olan ikinci segmenti yeniden iletecektir. ⓘ

Bir TCP göndericisi sıra dışı bir segment teslimatını kayıp bir segment olarak yorumlayabilir. Bunu yaparsa, TCP göndericisi sıra dışı paketten önceki segmenti yeniden iletecek ve o bağlantı için veri teslim hızını yavaşlatacaktır. Mayıs 2000'de RFC 2883'te tanımlanan SACK seçeneğinin bir uzantısı olan duplicate-SACK seçeneği bu sorunu çözer. TCP alıcısı hiçbir segmentin kaybolmadığını belirtmek için bir D-ACK gönderir ve TCP göndericisi daha sonra daha yüksek iletim hızını eski haline getirebilir. ⓘ

SACK seçeneği zorunlu değildir ve yalnızca her iki taraf da destekliyorsa devreye girer. Bu, bir bağlantı kurulduğunda müzakere edilir. SACK bir TCP başlık seçeneği kullanır (ayrıntılar için TCP segment yapısına bakın). SACK kullanımı yaygınlaşmıştır - tüm popüler TCP yığınları bunu destekler. Seçici onay, Akış Kontrol İletim Protokolü'nde (SCTP) de kullanılır. ⓘ

Pencere ölçeklendirme

Yüksek bant genişliğine sahip ağların daha verimli kullanılması için daha büyük bir TCP pencere boyutu kullanılabilir. TCP pencere boyutu alanı veri akışını kontrol eder ve değeri 2 ile 65.535 bayt arasında sınırlandırılmıştır. ⓘ

Boyut alanı genişletilemediğinden, bir ölçeklendirme faktörü kullanılır. RFC 1323'te tanımlanan TCP pencere ölçeği seçeneği, maksimum pencere boyutunu 65.535 bayttan 1 gigabayta çıkarmak için kullanılan bir seçenektir. Daha büyük pencere boyutlarına ölçeklendirme, TCP ayarlaması için gerekli olanın bir parçasıdır. ⓘ

Pencere ölçeği seçeneği yalnızca TCP 3 yönlü el sıkışma sırasında kullanılır. Pencere ölçeği değeri, 16 bitlik pencere boyutu alanının sola kaydırılacağı bit sayısını temsil eder. Pencere ölçeği değeri her yön için bağımsız olarak 0 (kaydırma yok) ile 14 arasında ayarlanabilir. Her iki yönde de pencere ölçeklendirmeyi etkinleştirmek için her iki tarafın da SYN segmentlerinde bu seçeneği göndermesi gerekir. ⓘ

Bazı yönlendiriciler ve paket güvenlik duvarları iletim sırasında pencere ölçeklendirme faktörünü yeniden yazar. Bu, gönderen ve alan tarafların farklı TCP pencere boyutları varsaymasına neden olur. Sonuç, çok yavaş olabilen, kararlı olmayan trafiktir. Bu sorun arızalı bir yönlendiricinin arkasındaki bazı sitelerde görülebilir. ⓘ

TCP zaman damgaları

1992'de RFC 1323'te tanımlanan TCP zaman damgaları, TCP'nin paketlerin hangi sırada gönderildiğini belirlemesine yardımcı olabilir. TCP zaman damgaları normalde sistem saatine göre hizalanmaz ve rastgele bir değerden başlar. Birçok işletim sistemi geçen her milisaniye için zaman damgasını artırır; ancak RFC yalnızca tiklerin orantılı olması gerektiğini belirtir. ⓘ

İki zaman damgası alanı vardır:

4 baytlık bir gönderici zaman damgası değeri (benim zaman damgam)

4 baytlık bir yankı yanıtı zaman damgası değeri (sizden alınan en son zaman damgası). ⓘ

TCP zaman damgaları, Sarılmış Sıra Numaralarına Karşı Koruma veya PAWS olarak bilinen bir algoritmada kullanılır (ayrıntılar için RFC 1323'e bakın). PAWS, alma penceresi sıra numarası sarma sınırını geçtiğinde kullanılır. Bir paketin potansiyel olarak yeniden iletildiği durumda şu soruyu yanıtlar: "Bu sıra numarası ilk 4 GB içinde mi yoksa ikinci sırada mı?" Ve zaman damgası eşitliği bozmak için kullanılır. ⓘ

Ayrıca, Eifel algılama algoritması (RFC 3522), paketlerin kaybolması ya da sadece sıra dışı olması nedeniyle yeniden iletimlerin gerçekleşip gerçekleşmediğini belirlemek için TCP zaman damgalarını kullanır. ⓘ

Son İstatistikler, Windows Server 2008'den bu yana Windows sunucusunun desteği bırakması nedeniyle Zaman Damgası benimseme seviyesinin ~%40 oranında durgunlaştığını göstermektedir. ⓘ

TCP zaman damgaları Linux çekirdeğinde varsayılan olarak etkinleştirilmiştir ve Windows Server 2008, 2012 ve 2016'da varsayılan olarak devre dışı bırakılmıştır. ⓘ

Bant dışı veri

Akışın bitmesini beklemek yerine kuyruğa alınan akışı kesmek veya iptal etmek mümkündür. Bu, verinin acil olarak belirtilmesiyle yapılır. Bu, alıcı programa acil verilerin geri kalanıyla birlikte hemen işlemesini söyler. İşi bittiğinde, TCP uygulamayı bilgilendirir ve akış kuyruğuna geri döner. TCP'nin uzaktan oturum açma oturumu için kullanılmasına bir örnek olarak, kullanıcı diğer uçtaki programı kesintiye uğratan veya iptal eden bir klavye dizisi gönderebilir. Bu sinyallere genellikle uzak makinedeki bir program düzgün çalışmadığında ihtiyaç duyulur. Sinyaller, programın mevcut aktarımını bitirmesini beklemeden gönderilmelidir. ⓘ

TCP bant dışı verileri modern İnternet için tasarlanmamıştır. Acil işaretçi yalnızca uzaktaki ana bilgisayardaki işlemi değiştirir ve ağın kendisinde herhangi bir işlemi hızlandırmaz. Uzak ana bilgisayara ulaştığında, protokolün biraz farklı iki yorumu vardır, bu da OOB verilerinin yalnızca tek baytlarının güvenilir olduğu anlamına gelir. Bu, en az kullanılan protokol öğelerinden biri olduğu ve kötü uygulanma eğiliminde olduğu için güvenilir olduğunu varsayar. ⓘ

Veri teslimatını zorlama

Normalde, TCP tam bir veri paketinin gönderilmesi için 200 ms bekler (Nagle Algoritması küçük mesajları tek bir pakette gruplamaya çalışır). Bu bekleme, bir dosya aktarımı sırasında sürekli tekrarlanırsa küçük ama potansiyel olarak ciddi gecikmeler yaratır. Örneğin, tipik bir gönderme bloğu 4 KB, tipik bir MSS 1460'tır, bu nedenle 10 Mbit/s ethernet üzerinde her biri ~1.2 ms süren 2 paket gider ve ardından TCP tam bir tampon beklediği için 197 ms'lik bir duraklamadan sonra kalan 1176'yı taşıyan üçüncü bir paket gelir. ⓘ

Telnet durumunda, her kullanıcı tuş vuruşu, kullanıcı ekranda göremeden önce sunucu tarafından geri yankılanır. Bu gecikme çok can sıkıcı olabilir. ⓘ

TCP_NODELAY soket seçeneğinin ayarlanması varsayılan 200 ms gönderme gecikmesini geçersiz kılar. Uygulama programları, bir karakter veya karakter satırı yazdıktan sonra çıktının gönderilmesini zorlamak için bu soket seçeneğini kullanır. ⓘ

RFC, PSH push bitini "alıcı TCP yığınına bu veriyi hemen alıcı uygulamaya göndermesi için bir mesaj" olarak tanımlar. Berkeley soketlerini kullanarak kullanıcı alanında bunu belirtmenin veya kontrol etmenin bir yolu yoktur ve yalnızca protokol yığını tarafından kontrol edilir. ⓘ

Güvenlik Açıkları

TCP çeşitli şekillerde saldırıya uğrayabilir. TCP'nin kapsamlı bir güvenlik değerlendirmesinin sonuçları ve tespit edilen sorunlar için olası hafifletmeler 2009 yılında yayınlanmıştır ve şu anda IETF içinde takip edilmektedir. ⓘ

Hizmet reddi

Saldırganlar sahte bir IP adresi kullanarak ve kasıtlı olarak bir araya getirilmiş SYN paketlerini ve ardından çok sayıda ACK paketini tekrar tekrar göndererek sunucunun sahte bağlantıları takip etmek için büyük miktarda kaynak tüketmesine neden olabilir. Bu, SYN flood saldırısı olarak bilinir. Bu soruna önerilen çözümler arasında SYN çerezleri ve kriptografik bulmacalar yer alır, ancak SYN çerezleri kendi güvenlik açıklarıyla birlikte gelir. Sockstress de benzer bir saldırıdır ve sistem kaynak yönetimi ile hafifletilebilir. TCP Persist Timer'ın istismarını içeren gelişmiş bir DoS saldırısı Phrack #66'da analiz edilmiştir. PUSH ve ACK floodları diğer varyantlardır. ⓘ

Bağlantı kaçırma

Bir TCP oturumunu dinleyebilen ve paketleri yeniden yönlendirebilen bir saldırgan bir TCP bağlantısını ele geçirebilir. Bunu yapmak için, saldırgan devam eden iletişimden sıra numarasını öğrenir ve akıştaki bir sonraki segment gibi görünen sahte bir segment oluşturur. Böyle basit bir kaçırma, bir paketin bir uçta hatalı olarak kabul edilmesine neden olabilir. Alıcı ana bilgisayar fazladan segmenti bağlantının diğer tarafına onayladığında, senkronizasyon kaybolur. Ele geçirme, ele geçirilen TCP bağlantısının kalıcı kontrolünü elde etmek için paket akışının kontrolünü ele geçirmeye izin veren Adres Çözümleme Protokolü (ARP) veya yönlendirme saldırılarıyla birleştirilebilir. ⓘ

İlk sıra numarasının kolayca tahmin edilebildiği RFC 1948'den önce farklı bir IP adresini taklit etmek zor değildi. Bu da saldırganın ARP ya da yönlendirme saldırılarına gerek kalmadan alıcının farklı bir IP adresinden geldiğine inanacağı bir dizi paketi körü körüne göndermesine olanak tanıyordu: taklit edilen IP adresinin meşru ana bilgisayarının kapalı olduğundan emin olmak ya da hizmet reddi saldırıları kullanarak bu duruma getirmek yeterliydi. Bu nedenle ilk sıra numarası artık rastgele seçilmektedir. ⓘ

TCP vetosu

Gizlice dinleyebilen ve gönderilecek bir sonraki paketin boyutunu tahmin edebilen bir saldırgan, alıcının mevcut bağlantıyı bozmadan kötü niyetli bir yükü kabul etmesine neden olabilir. Saldırgan, bir sonraki beklenen paketin sıra numarasına ve yük boyutuna sahip kötü amaçlı bir paket enjekte eder. Meşru paket nihayetinde alındığında, daha önce alınmış bir paketle aynı sıra numarasına ve uzunluğa sahip olduğu görülür ve normal bir kopya paket olarak sessizce düşürülür - meşru paket kötü niyetli paket tarafından "veto edilir". Bağlantı kaçırmanın aksine, bağlantı hiçbir zaman senkronize edilmez ve kötü amaçlı yük kabul edildikten sonra iletişim normal şekilde devam eder. TCP vetosu saldırgana iletişim üzerinde daha az kontrol sağlar, ancak saldırıyı tespit edilmeye karşı özellikle dirençli hale getirir. ACK fırtınasından kaynaklanan ağ trafiğindeki büyük artış önlenir. Alıcı için bir şeylerin yanlış gittiğine dair tek kanıt, IP ağında normal bir olay olan tek bir yinelenen pakettir. Veto edilen paketin göndericisi hiçbir zaman bir saldırı kanıtı görmez. ⓘ

Bir başka güvenlik açığı da TCP sıfırlama saldırısıdır. ⓘ

TCP bağlantı noktaları

TCP ve UDP, genellikle İnternet soketleri olarak adlandırılan bir ana bilgisayardaki gönderen ve alan uygulama uç noktalarını tanımlamak için bağlantı noktası numaralarını kullanır. Bir TCP bağlantısının her bir tarafı, gönderen veya alan uygulama tarafından ayrılmış 16 bitlik işaretsiz bir bağlantı noktası numarasına (0-65535) sahiptir. Gelen TCP paketlerinin belirli bir TCP bağlantısına ait olduğu soketlerinden, yani kaynak ana bilgisayar adresi, kaynak bağlantı noktası, hedef ana bilgisayar adresi ve hedef bağlantı noktası kombinasyonundan anlaşılır. Bu, bir sunucu bilgisayarın, bir istemci farklı kaynak bağlantı noktalarından bir hedef bağlantı noktasına eşzamanlı bağlantılar başlatmaya özen gösterdiği sürece, aynı anda birden fazla istemciye birden fazla hizmet sağlayabileceği anlamına gelir. ⓘ

Port numaraları üç temel kategoriye ayrılır: iyi bilinen, kayıtlı ve dinamik/özel. İyi bilinen bağlantı noktaları İnternet Atanmış Numaralar Kurumu (IANA) tarafından atanır ve genellikle sistem düzeyinde veya kök işlemler tarafından kullanılır. Sunucu olarak çalışan ve pasif olarak bağlantıları dinleyen iyi bilinen uygulamalar genellikle bu portları kullanır. Bazı örnekler şunlardır: FTP (20 ve 21), SSH (22), TELNET (23), SMTP (25), SSL/TLS üzerinden HTTP (443) ve HTTP (80). En son standart olan HTTP/3'ten itibaren TCP yerine QUIC'in aktarım olarak kullanıldığını unutmayın. Kayıtlı portlar genellikle son kullanıcı uygulamaları tarafından sunucularla iletişim kurarken geçici kaynak portları olarak kullanılır, ancak üçüncü bir tarafça kaydedilmiş adlandırılmış hizmetleri de tanımlayabilirler. Dinamik/özel portlar da son kullanıcı uygulamaları tarafından kullanılabilir, ancak daha az yaygındır. Dinamik/özel portlar herhangi bir TCP bağlantısı dışında herhangi bir anlam içermez. ⓘ

Ağ Adresi Çevirisi (NAT), genellikle bir genel ağ ile özel bir alt ağ arasında geçen trafik akışını belirsizleştirmek için ("İnternet'e bakan") genel tarafta dinamik bağlantı noktası numaralarını kullanır ve böylece alt ağdaki birçok IP adresine (ve bağlantı noktalarına) tek bir genel adres tarafından hizmet verilmesini sağlar. ⓘ

Gelişim

TCP karmaşık bir protokoldür. Bununla birlikte, yıllar içinde önemli geliştirmeler yapılmış ve önerilmiş olsa da, en temel çalışması 1974'teki ilk spesifikasyonu RFC 675'ten ve Eylül 1981'de yayınlanan v4 spesifikasyonu RFC 793'ten bu yana önemli ölçüde değişmemiştir. RFC 1122, İnternet Ana Bilgisayarları için Ana Bilgisayar Gereksinimleri, bir dizi TCP protokolü uygulama gereksinimine açıklık getirmiştir. Gerekli 8 spesifikasyonun ve şiddetle teşvik edilen 20'den fazla geliştirmenin bir listesi RFC 7414'te mevcuttur. Bu liste arasında, son yıllarda TCP ile ilgili en önemli RFC'lerden biri olan RFC 2581, TCP Tıkanıklık Kontrolü, gereksiz tıkanıklığı önleyen güncellenmiş algoritmaları açıklamaktadır. 2001 yılında RFC 3168, bir tıkanıklık önleme sinyal mekanizması olan Açık Tıkanıklık Bildirimi'ni (ECN) tanımlamak için yazılmıştır. ⓘ

Orijinal TCP tıkanıklık önleme algoritması "TCP Tahoe" olarak biliniyordu, ancak o zamandan beri birçok alternatif algoritma önerildi (TCP Reno, TCP Vegas, FAST TCP, TCP New Reno ve TCP Hybla dahil). ⓘ

TCP Interactive (iTCP), uygulamaların TCP olaylarına abone olmalarına ve uygulama destekli tıkanıklık kontrolü de dahil olmak üzere çeşitli amaçlar için uygulamaları başlatabilen işleyici bileşenlerini kaydetmelerine olanak tanıyan TCP uzantılarına yönelik bir araştırma çabasıdır. ⓘ

Çok Yollu TCP (MPTCP), kaynak kullanımını en üst düzeye çıkarmak ve yedekliliği artırmak için bir TCP bağlantısının birden fazla yol kullanmasına izin vermeyi amaçlayan IETF içinde devam eden bir çabadır. Kablosuz ağlar bağlamında Çok Yollu TCP tarafından sunulan yedeklilik, farklı ağların eşzamanlı olarak kullanılmasını sağlar, bu da daha yüksek verim ve daha iyi aktarım yetenekleri getirir. Çok Yollu TCP, veri merkezi ortamlarında da performans avantajları sağlar. Multipath TCP'nin referans uygulaması Linux çekirdeğinde geliştirilmektedir. Multipath TCP, iPhone, iPad ve Mac'lerde Siri ses tanıma uygulamasını desteklemek için kullanılmaktadır ⓘ

tcpcrypt, doğrudan TCP'nin kendisinde taşıma düzeyinde şifreleme sağlamak için Temmuz 2010'da önerilen bir uzantıdır. Şeffaf bir şekilde çalışmak ve herhangi bir yapılandırma gerektirmemek üzere tasarlanmıştır. TLS'nin (SSL) aksine, tcpcrypt'in kendisi kimlik doğrulama sağlamaz, ancak bunu yapmak için uygulamaya basit ilkeller sağlar. 2010 itibariyle, ilk tcpcrypt IETF taslağı yayınlanmıştır ve birkaç büyük platform için uygulamalar mevcuttur. ⓘ

TCP Fast Open, iki uç nokta arasında birbirini izleyen TCP bağlantılarının açılmasını hızlandıran bir uzantıdır. Kriptografik bir "çerez" kullanarak üç yönlü el sıkışmayı atlayarak çalışır. Güvenlik sorunları nedeniyle yaygın olarak benimsenmeyen T/TCP adlı daha önceki bir öneriye benzer. TCP Fast Open 2014 yılında RFC 7413 olarak yayınlanmıştır. ⓘ

Mayıs 2013'te önerilen Orantılı Hız Azaltma (PRR), Google mühendisleri tarafından geliştirilen bir TCP uzantısıdır. PRR, kurtarma işleminden sonra TCP pencere boyutunun mümkün olduğunca Yavaş başlatma eşiğine yakın olmasını sağlar. Algoritma, kurtarma hızını artırmak için tasarlanmıştır ve Linux 3.2+ çekirdeklerinde varsayılan tıkanıklık kontrol algoritmasıdır. ⓘ

Kullanımdan kaldırılan teklifler

TCP Çerez İşlemleri (TCPCT), sunucuları hizmet reddi saldırılarına karşı korumak için Aralık 2009'da önerilen bir uzantıdır. SYN çerezlerinin aksine TCPCT, pencere ölçeklendirme gibi diğer TCP uzantılarıyla çakışmaz. TCPCT, sunucuların çok sayıda kısa ömürlü TCP bağlantısını idare etmek zorunda olduğu DNSSEC gereklilikleri nedeniyle tasarlanmıştır. 2016 yılında TCPCT, TCP Fast Open lehine kullanımdan kaldırılmıştır. Orijinal RFC'nin durumu "tarihi" olarak değiştirildi. ⓘ

Kablosuz ağlar üzerinden TCP

TCP başlangıçta kablolu ağlar için tasarlanmıştır. Paket kaybının ağ tıkanıklığının bir sonucu olduğu düşünülür ve önlem olarak tıkanıklık penceresi boyutu önemli ölçüde azaltılır. Bununla birlikte, kablosuz bağlantıların solma, gölgelenme, el değiştirme, parazit ve kesinlikle tıkanıklık olmayan diğer radyo etkileri nedeniyle ara sıra ve genellikle geçici kayıplar yaşadığı bilinmektedir. Kablosuz paket kaybı nedeniyle tıkanıklık penceresi boyutunun (hatalı) geri çekilmesinden sonra, pencere boyutunda muhafazakar bir azalma ile tıkanıklıktan kaçınma aşaması olabilir. Bu da radyo bağlantısının yetersiz kullanılmasına neden olur. Bu zararlı etkilerle mücadele konusunda kapsamlı araştırmalar yapılmıştır. Önerilen çözümler, istemci veya sunucuda değişiklik gerektiren uçtan uca çözümler, hücresel ağlarda Radyo Bağlantı Protokolü (RLP) gibi bağlantı katmanı çözümleri veya uç düğümleri değiştirmeden ağda bazı değişiklikler gerektiren proxy tabanlı çözümler olarak kategorize edilebilir. ⓘ

Kablosuz sorununu çözmeye yardımcı olmak için Vegas, Westwood, Veno ve Santa Cruz gibi bir dizi alternatif tıkanıklık kontrol algoritması önerilmiştir. ⓘ

Donanım uygulamaları

TCP'nin işlem gücü gereksinimlerinin üstesinden gelmenin bir yolu, yaygın olarak TCP boşaltma motorları (TOE) olarak bilinen donanım uygulamalarını oluşturmaktır. TOE'lerin temel sorunu, bilgisayar sistemlerine entegre edilmelerinin zor olması ve bilgisayarın veya cihazın işletim sisteminde kapsamlı değişiklikler gerektirmesidir. Böyle bir cihaz geliştiren şirketlerden biri Alacritech'tir. ⓘ

Hata ayıklama

Bir ağ bağlantısındaki TCP trafiğini yakalayan bir paket dinleyici, kullanıcıya bir bağlantıdan hangi paketlerin geçtiğini göstererek ağlarda, ağ yığınlarında ve TCP kullanan uygulamalarda hata ayıklamada yararlı olabilir. Bazı ağ yığınları, setockopt kullanılarak soket üzerinde etkinleştirilebilen SO_DEBUG soket seçeneğini destekler. Bu seçenek, hata ayıklamada yardımcı olan tüm paketleri, TCP durumlarını ve soket üzerindeki olayları döker. Netstat, hata ayıklama için kullanılabilecek başka bir yardımcı programdır. ⓘ

Alternatifler

Birçok uygulama için TCP uygun değildir. Bir sorun (en azından normal uygulamalarda), uygulamanın kayıp bir paketten sonra gelen paketlere, kayıp paketin yeniden iletilen kopyası alınana kadar erişememesidir. Bu durum, medya akışı, gerçek zamanlı çok oyunculu oyunlar ve IP üzerinden ses (VoIP) gibi gerçek zamanlı uygulamalar için sorunlara neden olur; burada genellikle verilerin çoğunu zamanında almak, tüm verileri sırayla almaktan daha yararlıdır. ⓘ

Tarihsel ve performans nedenleriyle, çoğu depolama alanı ağı (SAN) Fiber Kanal bağlantıları üzerinden Fiber Kanal Protokolü (FCP) kullanır. ⓘ

Ayrıca, gömülü sistemler, ağ önyüklemesi ve çok sayıda istemciden gelen basit isteklere hizmet veren sunucular (örneğin DNS sunucuları) için TCP'nin karmaşıklığı bir sorun olabilir. Son olarak, her ikisi de NAT arkasında olan iki ana bilgisayar arasında veri iletimi (STUN veya benzer sistemler kullanarak) gibi bazı hileler, TCP gibi nispeten karmaşık bir protokol olmadan çok daha basittir. ⓘ

Genellikle TCP'nin uygun olmadığı durumlarda Kullanıcı Datagram Protokolü (UDP) kullanılır. Bu, TCP'nin yaptığı uygulama çoğullama ve sağlama toplamlarını sağlar, ancak akışları veya yeniden iletimi işlemez, uygulama geliştiricisine bunları duruma uygun bir şekilde kodlama veya ileri hata düzeltme veya enterpolasyon gibi diğer yöntemlerle değiştirme yeteneği verir. ⓘ

Stream Control Transmission Protocol (SCTP), TCP'ye benzer güvenilir akış odaklı hizmetler sağlayan başka bir protokoldür. TCP'den daha yeni ve çok daha karmaşıktır ve henüz yaygın olarak kullanılmamaktadır. Bununla birlikte, özellikle güvenilirlik ve gerçek zamana yakın hususların önemli olduğu durumlarda kullanılmak üzere tasarlanmıştır. ⓘ

Venturi Aktarım Protokolü (VTP), kablosuz veri aktarımıyla ilgili algılanan verimsizliklerin üstesinden gelmek için şeffaf bir şekilde TCP'nin yerini almak üzere tasarlanmış patentli tescilli bir protokoldür. ⓘ

TCP'nin yüksek bant genişliğine sahip ortamlarda da sorunları vardır. TCP tıkanıklık önleme algoritması, veri göndericisinin önceden bilinmediği ad-hoc ortamlar için çok iyi çalışır. Ortam öngörülebilirse, Asenkron Transfer Modu (ATM) gibi zamanlama tabanlı bir protokol TCP'nin yeniden iletim ek yükünü önleyebilir. ⓘ

UDP tabanlı Veri Aktarım Protokolü (UDT), yüksek bant genişliği-gecikme ürününe sahip ağlarda TCP'den daha iyi verimliliğe ve adalete sahiptir. ⓘ

Çok Amaçlı İşlem Protokolü (MTP/IP), özellikle TCP'nin verimsiz olarak algılandığı çok çeşitli ağ koşullarında uyarlamalı olarak yüksek verim ve işlem performansı elde etmek için tasarlanmış patentli tescilli bir yazılımdır. ⓘ

Checksum hesaplama

IPv4 için TCP sağlama toplamı

TCP IPv4 üzerinden çalıştığında, sağlama toplamını hesaplamak için kullanılan yöntem RFC 793'te tanımlanmıştır:

Sağlama toplamı alanı, başlık ve metindeki tüm 16 bitlik sözcüklerin bire tümleyen toplamının 16 bitlik bire tümleyenidir. Bir segment sağlama toplamı alınacak tek sayıda başlık ve metin sekizlisi içeriyorsa, son sekizlinin sağına sıfırlar eklenerek sağlama toplamı amacıyla 16 bitlik bir sözcük oluşturulur. Dolgu segmentin bir parçası olarak iletilmez. Sağlama toplamı hesaplanırken, sağlama toplamı alanının kendisi sıfırlarla değiştirilir. ⓘ

Başka bir deyişle, uygun dolgu işleminden sonra, tüm 16 bitlik sözcükler bire tümleyen aritmetiği kullanılarak toplanır. Toplam daha sonra bitsel olarak tamamlanır ve sağlama toplamı alanı olarak eklenir. Sağlama toplamı hesaplamasında kullanılan IPv4 paket başlığını taklit eden bir sözde başlık aşağıdaki tabloda gösterilmiştir. ⓘ

Sağlama toplamı hesaplaması için +TCP sözde başlığı (IPv4) ⓘ
Bit ofseti	0–3				4–7				8–15								16–31
0	Kaynak adres
32	Hedef adres
64	Sıfır								Protokol								TCP uzunluğu
96	Kaynak liman																Hedef bağlantı noktası
128	Sıra numarası
160	Onay numarası
192	Veri ofseti				Ayrılmış			Bayraklar									Pencere
224	Checksum																Acil işaretçi
256	Seçenekler (isteğe bağlı)
256/288+	Veri

Kaynak ve hedef adresler IPv4 başlığındaki adreslerdir. TCP için protokol değeri 6'dır (bkz. IP protokol numaraları listesi). TCP uzunluk alanı, TCP başlığının ve verisinin uzunluğudur (sekizli olarak ölçülür). ⓘ

IPv6 için TCP sağlama toplamı

TCP IPv6 üzerinden çalıştığında, RFC 2460 uyarınca sağlama toplamını hesaplamak için kullanılan yöntem değiştirilir:

Sağlama toplamı hesaplamasında IP başlığındaki adresleri içeren herhangi bir aktarım veya diğer üst katman protokolü, 32 bit IPv4 adresleri yerine 128 bit IPv6 adreslerini içerecek şekilde IPv6 üzerinde kullanım için değiştirilmelidir. ⓘ

Sağlama toplamının hesaplanması için IPv6 başlığını taklit eden bir sözde başlık aşağıda gösterilmiştir. ⓘ

Sağlama toplamı hesaplaması için +TCP sözde başlığı (IPv6) ⓘ
Bit ofseti	0–7								8–15								16–23								24–31
0	Kaynak adres
32
64
96
128	Hedef adres
160
192
224
256	TCP uzunluğu
288	Sıfır																								Sonraki başlık = Protokol
320	Kaynak liman																Hedef bağlantı noktası
352	Sıra numarası
384	Onay numarası
416	Veri ofseti				Ayrılmış				Bayraklar								Pencere
448	Checksum																Acil işaretçi
480	Seçenekler (isteğe bağlı)
480/512+	Veri

• Kaynak adresi: IPv6 başlığındaki adres
• Hedef adres: son hedef; IPv6 paketi bir Yönlendirme başlığı içermiyorsa, TCP IPv6 başlığındaki hedef adresi kullanır, aksi takdirde, kaynak düğümde Yönlendirme başlığının son öğesindeki adresi kullanır ve alıcı düğümde IPv6 başlığındaki hedef adresi kullanır.
• TCP uzunluğu: TCP başlığının ve verisinin uzunluğu
• Sonraki Başlık: TCP için protokol değeri ⓘ

Checksum boşaltma

Birçok TCP/IP yazılım yığını uygulaması, ağa iletimden önce veya doğrulama için ağdan alındıktan sonra ağ bağdaştırıcısındaki sağlama toplamını otomatik olarak hesaplamak için donanım yardımı kullanma seçenekleri sunar. Bu, işletim sistemini sağlama toplamını hesaplamak için değerli CPU döngülerini kullanmaktan kurtarabilir. Böylece genel ağ performansı artar. ⓘ

Bu özellik, sağlama toplamı yükünün kullanımından habersiz veya emin olmayan paket analizörlerinin, henüz ağ bağdaştırıcısına ulaşmamış giden paketlerde geçersiz sağlama toplamları bildirmesine neden olabilir. Bu durum yalnızca ağ bağdaştırıcısı tarafından iletilmeden önce durdurulan paketler için meydana gelecektir; ağ bağdaştırıcısı tarafından kablo üzerinden iletilen tüm paketler geçerli sağlama toplamlarına sahip olacaktır. Bu sorun, aynı ana bilgisayardaki sanal makineler arasında iletilen paketleri izlerken de ortaya çıkabilir; sanal aygıt sürücüsü, sağlama toplamının daha sonra VM ana bilgisayar çekirdeği veya fiziksel donanımı tarafından hesaplanacağını bilerek sağlama toplamı hesaplamasını (optimizasyon olarak) atlayabilir. ⓘ

RFC belgeleri

• RFC 675 - İnternet İletim Kontrol Programının Spesifikasyonu, Aralık 1974 Versiyonu
• RFC 793 - TCP v4
• RFC 1122 - TCP için bazı hata düzeltmeleri içerir
• RFC 1323 - Yüksek Performans için TCP Uzantıları [RFC 7323 tarafından yürürlükten kaldırıldı]
• RFC 1379 - İşlem Kavramları için TCP'nin Genişletilmesi [RFC 6247 tarafından yürürlükten kaldırılmıştır]
• RFC 1948 - Sıra Numarası Saldırılarına Karşı Savunma
• RFC 2018 - TCP Seçici Onay Seçenekleri
• RFC 5681 - TCP Tıkanıklık Kontrolü
• RFC 6247 - Kullanılmayan TCP Uzantıları RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644 ve RFC 1693'ün Tarihi Statüye Taşınması
• RFC 6298 - TCP'nin Yeniden İletim Zamanlayıcısının Hesaplanması
• RFC 6824 - Çoklu Adreslerle Çok Yollu Çalışma için TCP Uzantıları
• RFC 7323 - Yüksek Performans için TCP Uzantıları
• RFC 7414 - TCP Spesifikasyon Belgeleri için Bir Yol Haritası ⓘ

TCP bağlantısı nasıl kurulur?

A bilgisayarı B bilgisayarına TCP yoluyla bağlanmak istediğinde şu yol izlenir:

• A bilgisayarı B bilgisayarına TCP SYNchronize mesajı yollar
• B bilgisayarı A bilgisayarının isteğini aldığına dair bir TCP SYN+ACKnowledgement mesajı yollar
• A bilgisayarı B bilgisayarına TCP ACK mesajı yollar
• B bilgisayarı bir ACK "TCP connection is ESTABLISHED" mesajı alır

Üç zamanlı el sıkışma adı verilen bu yöntem sonucunda TCP bağlantısı açılmış olur. ⓘ

Veri iletimi

Bağlantı oluşturulduktan sonra, B bilgisayarı A bilgisayarından paketler almaya başlar. B, her aldığı paketten sonra bir süre bekledikten sonra en son düzgün olarak aldığı paket grubunu A'ya bildirir. Gelen bildirimlere göre A, daha sonra hangi paketleri yollaması gerektiğine karar verir ve yollar. Arada kaybolan paketler (veya paket alındı bilgileri) tekrar tekrar gönderir. ⓘ

TCP Segmenti

TCP bağlantı tabanlı (connection-oriented) bir protokoldür. TCP bağlantı tabanlı bir protokol olduğu için iki bilgisayar, üçlü el sıkışma (3-way handshaking) yaptıktan sonra veri alışverişi yapmaya başlar. ⓘ

TCP, taşıma katmanında verileri parçalara bölerek her bir parçanın önüne başlık bilgisi ekler. Başlık bilgisiyle birlikte bu veriye 'TCP Segmenti' denir. ⓘ

TCP Başlığı (TCP Header)

Offsets	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	Acknowledgment number (if ACK set)
12	96	Data offset				Reserved 0 0 0			N S	C W R	E C E	U R G	A C K	P S H	R S T	S Y N	F I N	Window Size
16	128	Checksum																Urgent pointer (if URG set)
20 ...	160 ...	Options (if data offset > 5. Padded at the end with "0" bytes if necessary.) ...

Kaynak Port (Source Port): Veriyi gönderen bilgisayarın kullandığı TCP portudur. ⓘ

Hedef Port (Destination Port): Hedef bilgisayarın TCP portudur. ⓘ

Sıra Numarası (Sequence Number): TCP'nin verinin böldüğü her bir segmentine verdiği numaradır. ⓘ

Onay Numarası (ACK Number): Alınan bir SYN paketine karşılık olan onay mesajı ACK biti ile gönderilir. ⓘ

Başlık Uzunluğu (Header Length/Data Offset): TCP başlığının uzunluğunu gösterir. ⓘ

Rezerve Edilmiş (Reserved): İleride kullanılmak üzere saklı tutulur. ⓘ

Kod Bitleri ya da Bayraklar (Code Bits or Flags): Segment ile ilgili kontrol bilgilerini taşır. ⓘ

Pencere (Window): Akış denetimi için kullanılır. ⓘ

Hata Kontrol Bitleri (Checksum): Segmentin hatalı ulaşıp ulaşmadığını kontrol etmek için kullanılır. ⓘ

Acil İşaretçisi (Urgent Pointer): Bir verinin acil olarak iletilmek istendiği durumlarda kullanılır. ⓘ

Seçenek (Option): TCP segmentinin maksimum boyutunun bilgisini taşır. ⓘ

Veri (Data):Verinin bulunduğu kısım. ⓘ