TCP是面向連接的通信協議，通過三次握手建立連接，通訊完成時要拆除連接，由于TCP是面向連接的所以只能用于端到端的通訊，
TCP提供的是一種可靠的資料流服務，采用“帶重傳的肯定確認”技術來實作傳輸的可靠性，TCP還采用一種稱為“滑動視窗”的方式進行流量控制，所謂出港口實際表示接收能力，用以限制發送方的發送速度，
如果TCP資料包有已經封好的TCP資料包，那么IP將把他們向“上”傳送到TCP層，TCP將包排序并進行錯誤檢查，同時實作虛電路間的連接，TCP資料包中包括序號和確認，所以未按照順序收到的包可以被排序，而損壞的包可以被重傳，
TCP將它的資訊送到更高層的應用程式，例如Trelnet的服務程式和客戶程式，應用程式輪流將資訊送回TCP層，TCP層便將它們向下傳送到IP層，設備驅動程式和物理介質，最后到接收方，
面向連接的服務（例如Telnet、Ftp、rlogin、X windows和SMTP）需要高度的可靠性，所以它們使用TCP，DNS在某些情況下使用TCP（發送和接受域名資料庫），但是用UDP傳送有關單個主機的資訊，
1、TCP三次握手
TCP提供面向有連接的通信傳輸，面向有連接是指在資料同你新年開始之前先做好兩端之間的準備作業，
所謂三次握手是指建立一個TCP連接時需要客戶端和服務端總共發送三個包以確認連接的建立，在socket編程中，這一程序有客戶戶端執行connect來觸發，
第一次握手：客戶端將標志位SYN置為1，隨機產生一個值seq=J，并將該資料包發送給服務器，客戶端進入SYN_SENT狀態，等待服務器端確認，
第二次握手：服務器端收到資料包后由編制為SYN=1知道客戶端請求建立連接，服務器端將標志位SYN和ACK都置位1，ack=J+1，隨機產生一個值seq=K，并將改資料包發送給客戶端以確認連接請求，服務器端進入SYN_RCVD狀態，
第三次握手：客戶端收到確認后，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK置位1，ack=K+1，并將改資料包發送給服務器端，服務器端檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，客戶端和服務器端進入ESTABLISHED狀態，完成三次握手，隨后客戶端與服務端之間可以開始傳輸資料了，
2、 TCP的三次握手的漏洞
但是在TCP三次握手中有一個缺陷，就是如果我們利用三次握手的缺陷進行攻擊，這個攻擊就是SYN洪泛攻擊，三次握手中有一個第二次握手，服務端向客戶端應答請求，應答請求時需要客戶端IP的，服務端是需要知道客戶端IP的，攻擊者就偽造這個IP，往服務器端狂發第一次握手的內容，當然第一次握手中的客戶端IP地址是偽造的，從而服務端忙于進行第二次握手但是第二次握手當然沒有結果，所以導致服務端被拖累，死機，
面對這種攻擊，有以下的解決方案，最好的方案是防火墻，
無效連接監視釋放
這種方法不停監視所有的連接，包括三次握手的，還有握手一次的，反正是所有的，當達到一定閾值是拆除這些連接，從而釋放系統資源，這種方法對于所有的連接一視同仁，不管是正常還是工技大額，所以這種方式不推薦，
延緩TCB分配方法
一般做完第一次握手之后，服務器就需要為改請求分配一個TCB（連接控制資源），通常這個資源需要200多個位元組，延遲TCB的分配，當正常連接建立起來后在分配TCB則可以有效地減輕服務器資源的消耗，
使用防火墻
防火墻在確認了連接的有效性后，才向內部的服務器（Listener）發起SYN請求
3、TCP四次揮手（分手）
四次揮手即終止TCP連接，就是指斷開一個TCP連接時，需要客戶端和服務端總共發送4個包確認連接的斷開，在socket編程中，這一程序客戶端或服務端任一方執行close來觸發
由于TCP連接時全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成資料發送任務后，發送一個FIIN來終止之一方向的連接，收到一個FIN只是意味著這一方向上沒有資料流動了，即不會再收到資料了，但是在這個TCP連接上任然能夠發送資料，直到這一方向也發送了FIN，首先進行關閉的一方將執行主動關閉，而另一方則執行被動關閉，
1、客戶端行程發出連接釋放報文，并且停止發送資料，釋放資料報文首部FIN=1，其序號為seq=u（等于前面已經傳送過來的資料的最后一個位元組的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態，TCP規定，FIN報文段即使不攜帶資料也要消耗一個序號，
2、服務器收到連接釋放的報文，發出確認報文，ACK=1,ack=u+1，并且帶上位元組序列號seq=v，此時，服務器進入CLOSE-WAIT（關閉等待）狀態，TCP服務器通知高層的應用行程，客戶端向服務器的方向就釋放了，這時候處于半關閉狀態，及客戶端已經沒有資料要發送了，但是服務器若發送資料，客戶端依然要接受，這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的 時間，
3、客戶端收到服務器端的確認請求后，此時，客戶端進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送鏈接釋放報文（在這之前還需要接受服務器發送的最后的資料），
4、服務器將最后的資料發送完畢后，就向客戶端發送連接釋放報文，FIN=1，ack=u+1，由于在半關閉狀態，服務器很可能有發送一些資料，假定此時的序列號為sqp=w，此時，服務器就進入LAST-ACK（最后確認）狀態，等待客戶端的確認，
5、客戶端收到服務器的連接釋放報文后，必須發出確認，ACK=1，ack=w+1，而自己的徐磊好是seq=u+1，此時，客戶端就進入2*MSL（最長報文段壽命）的時間后，當客戶端撤銷相應的TCB后，才進入CLOSED狀態，
服務器只要收到客戶端發出的確認，立即進入CLOSED狀態，同樣，撤銷TCB后，就結束了這次的TCP連接，可以看到，服務器結束TCP連接的書簡要比客戶端早一些，
4、TCP的通訊原理
⑴、Socket套接字
Socket的愿意是“插座”，在計算機通信領域，scoket被翻譯成“套接字，它是計算機之間進行通信的一種約定或一種方式”，通過socket這種約定，一臺計算機可以接收其他計算機的資料，也可以向其他計算機發送資料，TCP用主機的IP地址加上主機的埠號作為TCP連接的端點，這種端點就叫做套接字（scoket），
區分不同應用程式行程間的網路通信和連接，主要有3個引數：通信的目的IP地址、使用的傳輸層協議（TCP或UDP）和使用的埠號，通過將3個引數結合起來，與一個“插座”socket系結，應用層就可以和傳輸層套接字介面區分來自不同應用行程或網路連接的通信，實作資料傳輸的并發服務，
套接字對是一個定義該連接的兩個端點的四元組：本地IP地址、本地TCP埠號、外地IP地址、外地TCP埠號，套接字對唯一便是一個網路上的每個TCP連接，
⑵、TCP緩沖區
每個TCP的socket的內核中都有一個發送緩沖區和一個接受緩沖區，現在我們假設用write()方法發送資料，使用read()方法接受資料，
Write()并不立即向網路中傳輸資料，而是先將資料寫入緩沖區中，再由TCP協議將資料從緩沖區發送到目標機器，一旦將資料寫入緩沖區，函式就可以成功回傳，不管它們有沒有到達目標機器，也不管它們合適發送到網路，這些都是TCP協議負責的事情，
TCP協議獨立于write()函式，資料有可能剛被寫入緩沖區就被發送到網路，也可能在緩沖區不斷積壓，多次寫入的資料被一次性發送到網路，這就取決于當時的網路情況、當前執行緒是否空閑等諸多因素，不有程式員控制，
Read()也是如此，也從輸入緩沖區中讀取資料，而不是直接從網路中讀取，
總的來說，I/O緩沖區自在每個TCP套接字中單獨存在；I/O緩沖區在創建套接字時自動生成，
TCP的可靠性性
在TCP中，當發送端的資料到達接收主機時，接收端主句會回傳一個已收到訊息的通知，這個訊息叫做確認應答（ACK），當發送端將資料發出之后會等待對端的確認應答，如果有確認應答，說明資料已經成功到達對端，反之，則資料丟失的可能性很大，
在一定時間內沒有等待到確認應答，發送端就可以認為資料已經丟失，并進行重發，由此，即使產生了丟包，仍然能保證書能夠到達對端，實作可靠傳輸，
為收到確認應答并不意味著資料一定丟失，也有可能是資料對方已經收到，只是回傳的確認應答在途中丟失，這種情況也會導致發送端誤以為資料沒有到達目的地而重發資料，
此外，也有可能因為一些其他原因導致確認應答延遲到達，在源主句重發資料以后才到達的情況也屢見不鮮，此時，源主機只要按斬訓制重發資料即可，
對于目標主機來說，反復收到相同的資料是不可取的，為了對上層應用提供可靠的傳輸，目標主機必須放棄重復的資料包，位置我們引進了序列號，、
序列號是按照順序給發送資料的每一個位元組（8位位元組）都標上號碼的編號，接受端查詢接收資料TCP首部中的序列號和資料的長度，將自己下一步應該接收的序列號作為確認應答回傳，通過序列號和確認應答號，TCP能都識別是否已經接收資料，又能夠判斷是否需要接收，從而實作可靠傳輸，
TCP的滑動視窗
發送方和接收方都會維護一個資料幀的序列，這個序列被稱為視窗，發送方的視窗大小由接收方確認，目的是控制發送速度，一面接收方的快取不夠大導致溢位，同時控制流量也可以避免網路擁塞，
在TCP的可靠性的圖中，我們可以看到，發送方每發送一個資料接收方就要給發送發一個ACK對這個資料進行確認，只有接受了這個確認資料以后發送發才能傳輸下個資料，
存在的問題：如果視窗過小，當傳輸比較大的資料的時候需要不停的對資料進行確認這個時候就會造成很大的延遲，
如果視窗過大，我們假設發送發一次發送100個資料，但是接收方只能處理50個資料，這樣每次都只能處理50個資料進行確認，發送方下一次還是要發送100個資料，但是接收方還是只能處理50個資料，這樣就避免了不必要的資料來擁塞我們的鏈路，
因此，我們引入了滑動視窗，滑動視窗通俗來講就是一種流量控制技術，
它本質上市描述接收方的TCP資料緩沖區大小的資料，發送方根據這個資料來計算自己嘴都能發送多長的資料，如果發送方收到接收方的視窗大小為0的TCP數報，那么發送方就停止發送資料，等到接收方發送視窗大小不為0的資料報的到來，
首先是第一次發送資料，這個時候的視窗大小是根據鏈路寬帶的大小來決定的，我們假設這個時候視窗的大小是3，這個時候接收方收到資料以后會對資料進行確認告訴發送方我下次希望收到的資料是多少，這里我們看到接收方發送的ACK=3（這是發送方發送序列2的回答確認，下一次接收方希望接受到的是3序列信號），這個時候發送方收到這個資料以后就知道我第一次發送的3個資料對方只收到2個，就知道第3個資料對方沒有收到，下次在發送的時候就從第3個資料開始發，
此時視窗大小變成2，
于是發送方發送2個資料，看到接收方發送的ACK 是5就表示它下一次希望收到的資料是5，發送方就知道我剛才發送的2個資料對方收了，這個時候發送第5個資料，
這就是滑動視窗的作業機制，當鏈路變好了或者變差了這個視窗還會發生變化，并不是第一次協商好以后就永遠不變了，
所以滑動視窗協議，是TCP使用的一種流量控制方法，改協議允許發送方在停止并等待確認前可以連續發送多個分組，由于發送方不必每2發一個分組就停下來等待確認，因此該協議可以加速資料的傳輸，
只有在接受視窗向前滑動時（與此同時也發送確認），發送視窗才有可能向前滑動，
收發兩端的視窗按照以上規律不斷向前滑動，因此這種協議又稱為滑動視窗協議，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/47364.html
標籤：其他
上一篇：求個華三Ap的韌體，萬分感謝
下一篇：驅動編程問題來個大佬