tcpnagle演算法

Ⅰ 求編程領域上一些經典演算法同時也是程序員必須掌握的演算法

這是我在一個論壇里看到的，你也參考參考吧。C++的虛函數
======================
C++使用虛函數實現了其對象的多態，C++對象的開始四個位元組是指向虛函數表的指針，其初始化順序是先基類後派生類，所以該虛函數表永遠指向最後一個派生類，從而實現了相同函數在不同對象中的不同行為，使得對象既有共性，又有其個性。

內存池分配、回收之夥伴演算法
=======================
夥伴演算法是空閑鏈表法的一個增強演算法，依次建立2^0\2^1\2^2\2^3...2^n大小的 內存塊空閑鏈表，利用相鄰內存塊的夥伴性質，很容易將互為夥伴的內存塊進行合並移到相應的空閑鏈表或將一塊內存拆分成兩塊夥伴內存，一塊分配出去，另一塊掛入相應空閑鏈表，使得內存的分配和回收變得高效。

AVL樹
=======================
AVL樹是一個平衡二叉樹，其中序遍歷是從小到大排序的，該結構插入節點和檢索非常高效，被廣泛應用

快速排序
=======================
通過一趟排序將要排序的數據分割成獨立的兩部分，其中一部分的所有數據都比另外一部分的所有數據都要小，然後再按此方法對這兩部分數據分別進行快速排序，整個排序過程可以遞歸進行，以此達到整個數據變成有序序列。效率非常高

密碼學之非對稱加密協議（公鑰、私鑰加密協議）
======================
非對稱加密演算法需要兩個密鑰，用其中一個加密產生的密文，只能通過另外一個密鑰解密，密鑰持有者A可以將其中一個公開，稱為公用密鑰，另外一個秘密保存稱為私鑰，這樣當某人B想給A傳一封秘信時，只要將密信使用A的公鑰加密後，就可以放心使用各種信道將迷信傳給A了，因為該密信只有A可以解密，第三者截取因為無法解密而毫無意義。
該演算法很好地解決了密鑰的安全傳遞的問題，因為公鑰和加密演算法都是公開的，私鑰不需要傳輸。

密碼學之數字簽名協議（身份鑒別、防抵賴）
======================
數字簽名也是建立在非對稱加密基礎之上的，如果A君用它的私鑰將文件加密後在發布，A君就無法抵賴該文件是其發布的，因為其他人能通過A君的公鑰將文件解密就說明，如果演算法可靠，該文件一定是A君用其私鑰加密的。
由於非對稱加密演算法的加密和解密很慢，現在的數字簽名並非是將其要發布的信息用其私鑰加密，而是先用一個單項散列演算法如（MD5）產生一個該信息的比較短的指紋（hash值），對其指紋用其私鑰加密後和信息一並發布，同樣達到了防抵賴的作用。

無回溯字元串模式匹配-kmp演算法
======================
他是根據子串的特徵，當匹配失敗時，不需要回溯，而是直接將字串向後滑動若干個位元組，繼續匹配，極大提高了匹配速度。該演算法被廣泛使用。詳細請參考數據結構教程。

最小路徑選路-迪傑斯特拉演算法、弗洛伊德演算法
======================
學習數據結構的時候，印象最深的就要算kmp演算法和最小路徑演算法了，因為理解他們比較費腦子，我是不可能發明這些演算法了，發明他們的都是天才，呵呵。
使用最短路徑的演算法曾經幫人寫過一個小東西，還是很有效的，記得是使用的弗洛伊德演算法的一個變種，要詳細了解的朋友可以查找相關資料，想將他們使用在你的項目中，代碼直接從教科書上抄就可以了，不需要理解。

tcp協議之-nagle演算法
======================
tcp、ip中令人叫絕的想法很多，印象最深的要算nagle演算法了。
tcp出於效率和流量控制的考慮，發送端的數據不是產生多少就馬上發送多少，一般是等到數據集聚到發送緩沖區長度的一半或者數據達到最大tcp數據包數據部分長度（好像是65515）才啟動發送，而且還要看接受端可用緩沖區的大小，如果接受端產生一個回應報文通知發送端沒有接受空間了，發送端哪怕緩沖區已經滿了，也不會啟動發送，直到接受端通告發送端其已經有了接受數據的空間了。
這樣就有一個問題，假如發送端就是要發送一個小報文（比如10個位元組），然後等待對方的回應。按照上面的方案，tcp會一直等數據收集到一定量才發送，於是矛盾就產生了。應用層不再發數據，tcp等不到足夠的數據不會將10個字的數據發送到網卡，接收端應用層收不到數據就不會回應發送端。
你也可能說，可以讓修改發送端發送條件，不一定要等到足夠的數據再發送，為了效率考慮，可以考慮延時一定的時間，比如說1秒，如果上層還沒有數據到來，就將發送緩沖中的數據發出去。當然這樣也是可行的，盡管應用端白白等了1秒鍾啥也沒干，呵呵。
其實nagle演算法很好解決了該問題，它的做發是鏈接建立後的第一次發送不用等待，直接將數據組裝成tcp報文發送出去，以後要麼等到數據量足夠多、要麼是等到接受方的確認報文，演算法及其簡單，而且很好解決了上面的矛盾。

socket之io模型設計
======================
windows下socket有兩種工作方式：
1）同步方式
2）非同步方式

同步socket又有兩種工作模式：
1）阻塞模式
2）非阻塞模式

阻塞模式是最簡單的工作模式，以tcp的發送數據為例，如果發送緩沖區沒有空間，send調用就不會返回，一直要等到能夠發出一點數據為止，哪怕是一個位元組，但是send返回並不表示我要發送的數據已經全部提交給了tcp，所以send返回時要檢查這次發送的數量，調整發送緩沖指針，繼續發送，直到所有數據都提交給了系統。
由於其阻塞的特性，會阻塞發送線程，所以單線程的程序是不適合使用阻塞模式通信的，一般使用一個連接一個線程的方法，但是這種方式對於要維護多個連接的程序，是個不好的選擇，線程越多，開銷越大。

同步非阻塞模式的socket不會阻塞通信線程，如果發送緩沖區滿，send調用也是立刻返回，接受緩沖區空，recv也不會阻塞，所以通信線程要反復調用send或recv嘗試發送或接收數據，對cpu是很大的浪費。
針對非阻塞的尷尬，介面開發人員發明了三種io模型來解決該問題：
1）選擇模型（select）
2）非同步選擇模型（AsyncSelect）
3）事件選擇模型（EventSeselect）
其思想是根據io類型，預先查看1個或n個socket是否能讀、寫等。
其select本身來說，select是阻塞的，可以同時監視多個socket，只要所監視的其中一個socket可以讀、寫，secect調用才返回
非同步選擇模型其select是非同步的（非同步是不會阻塞的），是將監視任務委託給系統，系統在socket可讀、寫時通過消息通知應用程序。有一點需要說明，假如應用程序已經有很多數據需要發送，當收到可寫通知時，一定要盡量多地發送數據，直到發送失敗，lasterror提示「將要阻塞」，將來才可能有新的可寫通知到來，否則永遠也不會有。
事件選擇模型也是將監視socket狀態的工作委託給系統，系統在適當的時候通過事件通知應用程序socket可以的操作。

除了同步工作方式外，還有一種叫非同步工作方式
非同步工作方式是不會阻塞的，因為是將io操作本身委託給系統，系統在io操作完成後通過回調常式或事件或完成包通知應用程序
非同步工作方式有兩種io模型和其對應，其實這兩種模型是window是非同步io的實現：
1）重疊模型
2）完成埠

重疊模型通過事件或回調常式通知應用程序io已經完成
完成埠模型比較復雜，完成埠本身其實是一個io完成包隊列。
應用程序一般創建若干個線程用來監視完成埠，這些線程試圖從完成埠移除一個完成包，如果有，移除成功，應用程序處理該完成包，否則應用程序監視完成埠的線程被阻塞。

select模型是從UNIX上的Berkeley Software Distribution(BSD)版本的套接字就實現了的，其它四種io模型windows發明的，在windows中完成埠和非同步選擇模型是使用比較廣泛的，一般分別用於服務端和客戶端開發。
這五種io模型設計還是比較巧妙的：三種選擇模型很好解決了「同步非阻塞」模式編程的不足；重疊模型和完成埠是windows非同步io的經典實現，不局限於網路io，對文件io同樣適用。

說點題外話，socket的send完成僅僅是將數據（可能是部分）提交給系統，而不是已經發送到了網卡上，更不是已經發送到了接收端。所以要知道你的數據已經發送到了對方的應用層的唯一方法是，讓對方給你發送一個應對包。
發送數據要注意，對應tcp，要防止發送和接收的亂序，對於發送，一般應該為每一個鏈接建立一個發送隊列，採用類似nagle的演算法啟動數據發送。
一次發送可能是你提交數據的一部分，一定要當心，否則出問題沒處找去。

Ⅱ 設置tcp哪個socket參數 nagle演算法

UDP和TCP編程步驟也有些不同，如下：TCP編程的伺服器端一般步驟是：1、創建一個socket，用函數socket()；2、設置socket屬性，用函數setsockopt();*可選3、綁定IP地址、埠等信息到socket上，用函數bind();4、開啟監聽，用函數listen()；5、接收客戶端上來的連接，用函數accept()；6、收發數據，用函數send()和recv()，或者read()和write();7、關閉網路連接；8、關閉監聽；TCP編程的客戶端一般步驟是：1、創建一個socket，用函數socket()；2、設置socket屬性，用函數setsockopt();*可選3、綁定IP地址、埠等信息到socket上，用函數bind();*可選4、設置要連接的對方的IP地址和埠等屬性；5、連接伺服器，用函數connect()；6、收發數據，用函數send()和recv()，或者read()和write();7、關閉網路連接；與之對應的UDP編程步驟要簡單許多，分別如下：UDP編程的伺服器端一般步驟是：1、創建一個socket，用函數socket()；2、設置socket屬性，用函數setsockopt();*可選3、綁定IP地址、埠等信息到socket上，用函數bind();4、循環接收數據，用函數recvfrom();5、關閉網路連接；UDP編程的客戶端一般步驟是：1、創建一個socket，用函數socket()；2、設置socket屬性，用函數setsockopt();*可選3、綁定IP地址、埠等信息到socket上，用函數bind();*可選4、設置對方的IP地址和埠等屬性;5、發送數據，用函數sendto();6、關閉網路連接；

Ⅲ tcp協議通過什麼來區分不同的連接

TCP/IP
不同的計算機系統，就好像語言不同的兩個人互相見了面，完全不能交流信息。因而他們需要定義一些共通的東西來進行交流，TCP/IP就是為此而生。TCP/IP不是一個協議，而是一個協議族的統稱。裡麵包括了IP協議，IMCP協議，TCP協議，以及我們更加熟悉的http、ftp、pop3協議等等。電腦有了這些，就好像學會了外語一樣，就可以和其他的計算機終端做自由的交流了。
TCP/IP 層次
應用層(http、ftp、smtp) -->傳輸層(TCP、UDP)-->網路層(IP)-->數據鏈路層
域名系統 :域名系統是一個分布的資料庫，它提供將主機名（就是網址啦）轉換成IP地址的服務。
埠號(port): 注意，這個號碼是用在TCP，UDP上的一個邏輯號碼，並不是一個硬體埠，我們平時說把某某埠封掉了，也只是在IP層次把帶有這個號碼的IP包給過濾掉了而已。
應用編程介面:現在常用的編程介面有socket和TLI。
數據鏈路層
數據鏈路層有三個目的：
為IP模塊發送和 接收IP數據報。
為ARP模塊發送ARP請求和接收ARP應答。
為RARP發送RARP請 求和接收RARP應答
ip大家都聽說過。至於ARP和RARP，ARP叫做地址解析協議，是用IP地址換MAC地址的一種協議，而RARP則叫做逆地址解析協議.
--
IP 、ARP 、RARP 協議
三者都是在網路層 ，ARP協議用來找到目標主機的Ethernet網卡Mac地址，IP則承載要發送的消息。數據鏈路層可以從ARP得到數據的傳送信息，而從IP得到要傳輸的數據信息。
IP 協議
IP協議是TCP/IP協議的核心，所有的TCP，UDP，IMCP，IGCP的數據都以IP數據格式傳輸。要注意的是，IP不是可靠的協議，這是說，IP協議沒有提供一種數據未傳達以後的處理機制－－這被認為是上層協議：TCP或UDP要做的事情。所以這也就出現了TCP是一個可靠的協議，而UDP就沒有那麼可靠的區別。

協議頭
八位的TTL欄位，還記得這個欄位是做什麼的么？這個欄位規定該數據包在穿過多少個路由之後才會被拋棄(這里就體現出來IP協議包的不可靠性，它不保證數據被送達)，某個ip數據包每穿過一個路由器，該數據包的TTL數值就會減少1，當該數據包的TTL成為零，它就會被自動拋棄。這個欄位的最大值也就是255，也就是說一個協議包也就在路由器裡面穿行255次就會被拋棄了，根據系統的不同，這個數字也不一樣，一般是32或者是64，Tracerouter這個工具就是用這個原理工作的，tranceroute的-m選項要求最大值是255，也就是因為這個TTL在IP協議裡面只有8bit。
現在的ip版本號是4，所以也稱作IPv4。現在還有IPv6，而且運用也越來越廣泛了。
IP路由選擇
當一個IP數據包準備好了的時候，IP數據包（或者說是路由器）是如何將數據包送到目的地的呢？它是怎麼選擇一個合適的路徑來"送貨"的呢？
最特殊的情況是目的主機和主機直連，那麼主機根本不用尋找路由，直接把數據傳遞過去就可以了。至於是怎麼直接傳遞的，這就要靠ARP協議了。
稍微一般一點的情況是，主機通過若干個路由器(router)和目的主機連接。那麼路由器就要通過ip包的信息來為ip包尋找到一個合適的目標來進行傳遞，比如合適的主機，或者合適的路由。路由器或者主機將會用如下的方式來處理某一個IP數據包
如果IP數據包的TTL（生命周期）以到，則該IP數據包就被拋棄。
搜索路由表，優先搜索匹配主機，如果能找到和IP地址完全一致的目標主機，則將該包發向目標主機
搜索路由表，如果匹配主機失敗，則匹配同子網的路由器，這需要「子網掩碼(1.3.)」的協助。如果找到路由器，則將該包發向路由器。
搜索路由表，如果匹配同子網路由器失敗，則匹配同網號路由器，如果找到路由器，則將該包發向路由器。
搜索路由表，如果以上都失敗了，就搜索默認路由，如果默認路由存在，則發包
如果都失敗了，就丟掉這個包
這再一次證明了，ip包是不可靠的。因為它不保證送達。
ARP協議
還記得數據鏈路層的乙太網的協議中，每一個數據包都有一個MAC地址頭么？我們知道每一塊乙太網卡都有一個MAC地址，這個地址是唯一的，那麼IP包是如何知道這個MAC地址的？這就是ARP協議的工作。
ARP（地址解析）協議是一種解析協議，本來主機是完全不知道這個IP對應的是哪個主機的哪個介面，當主機要發送一個IP包的時候，會首先查一下自己的ARP高速緩存（就是一個IP-MAC地址對應表緩存），如果查詢的IP－MAC值對不存在，那麼主機就向網路發送一個ARP協議廣播包，這個廣播包裡面就有待查詢的IP地址，而直接收到這份廣播的包的所有主機都會查詢自己的IP地址，如果收到廣播包的某一個主機發現自己符合條件，那麼就准備好一個包含自己的MAC地址的ARP包傳送給發送ARP廣播的主機，而廣播主機拿到ARP包後會更新自己的ARP緩存（就是存放IP-MAC對應表的地方）。發送廣播的主機就會用新的ARP緩存數據准備好數據鏈路層的的數據包發送工作。
arp -a 可以查詢自己的arp緩存
這樣的高速緩存是有時限的，一般是20分鍾（伯克利系統的衍生系統）。
--
ICMP協議
--
UDP 協議
UDP是傳輸層協議，和TCP協議處於一個分層中，但是與TCP協議不同，UDP協議並不提供超時重傳，出錯重傳等功能，也就是說其是不可靠的協議。
1 、UDP 的埠號
由於很多軟體需要用到UDP協議，所以UDP協議必須通過某個標志用以區分不同的程序所需要的數據包。埠號的功能就在於此，例如某一個UDP程序A在系統中注冊了3000埠，那麼，以後從外面傳進來的目的埠號為3000的UDP包都會交給該程序。埠號理論上可以有2^16這么多。因為它的長度是16個bit
2 、UDP 的檢驗和
這是一個可選的選項，並不是所有的系統都對UDP數據包加以檢驗和數據(相對TCP協議的必須來說)，但是RFC中標准要求，發送端應該計算檢驗和。
UDP檢驗和覆蓋UDP協議頭和數據，這和IP的檢驗和是不同的，IP協議的檢驗和只是覆蓋IP數據頭，並不覆蓋所有的數據。UDP和TCP都包含一個偽首部，這是為了計算檢驗和而攝制的。偽首部甚至還包含IP地址這樣的IP協議裡面都有的信息，目的是讓UDP兩次檢查數據是否已經正確到達目的地。如果發送端沒有打開檢驗和選項，而接收端計算檢驗和有差錯，那麼UDP數據將會被悄悄的丟掉（不保證送達），而不產生任何差錯報文。
3 、UDP 的長度
UDP可以很長很長，可以有65535位元組那麼長。但是一般網路在傳送的時候，一次一般傳送不了那麼長的協議（涉及到MTU的問題），就只好對數據分片，當然，這些是對UDP等上級協議透明的，UDP不需要關心IP協議層對數據如何分片。
4 、IP 分片
IP在從上層接到數據以後，要根據IP地址來判斷從那個介面發送數據（通過選路），並進行MTU的查詢，如果數據大小超過MTU就進行數據分片。數據的分片是對上層和下層透明，而數據也只是到達目的地還會被重新組裝，不過不用擔心，IP層提供了足夠的信息進行數據的再組裝。
在IP頭裡面，16bit識別號唯一記錄了一個IP包的ID,具有同一個ID的IP片將會被重新組裝；而13位片偏移則記錄了某IP片相對整個包的位置；而這兩個表示中間的3bit標志則標示著該分片後面是否還有新的分片。這三個標示就組成了IP分片的所有信息，接受方就可以利用這些信息對IP數據進行重新組織（就算是後面的分片比前面的分片先到，這些信息也是足夠了）。
因為分片技術在網路上被經常的使用，所以偽造IP分片包進行流氓攻擊的軟體和人也就層出不窮。
5 、ICMP源站抑制差錯
當目標主機的處理速度趕不上數據接收的速度，因為接受主機的IP層緩存會被占滿，所以主機就會發出一個「我受不了」的一個ICMP報文。
--
單播廣播和多播
單播
單播是說，對特定的主機進行數據傳送。例如給某一個主機發送IP數據包。這時候，數據鏈路層給出的數據頭裡面是非常具體的目的地址，對於乙太網來 說，就是網卡的MAC地址（不是FF-FF-FF-FF-FF-FF這樣的地址）。現在的具有路由功能的主機應該可以將單播數據定向轉發，而目的主機的網 絡介面則可以過濾掉和自己MAC地址不一致的數據。
廣播
廣播是主機針對某一個網路上的所有主機發送數據包。這個網路可能是網路，可能是子網，還可能是所有的子網。如果是網路，例如A類網址的廣播就是 netid.255.255.255，如果是子網，則是netid.netid.subnetid.255；如果是所有的子網（B類IP）則是則是 netid.netid.255.255。廣播所用的MAC地址FF-FF-FF-FF-FF-FF。網路內所有的主機都會收到這個廣播數據，網卡只要把 MAC地址為FF-FF-FF-FF-FF-FF的數據交給內核就可以了。一般說來ARP，或者路由協議RIP應該是以廣播的形式播發的。
多播
可以說廣播是多播的特例，多播就是給一組特定的主機（多播組）發送數據，這樣，數據的播發范圍會小一些(實際上播發的范圍一點也沒有變小)，多播的MAC地址是最高位元組的低位為一，例 如01-00-00-00-00-00。多播組的地址是D類IP，規定是224.0.0.0-239.255.255.255。
雖然多播比較特殊，但是究其原理，多播的數據還是要通過數據鏈路層進行MAC地址綁定然後進行發送。所以一個乙太網卡在綁定了一個多播IP地址之後，必 定還要綁定一個多播的MAC地址，才能使得其可以像單播那樣工作。這個多播的IP和多播MAC地址有一個對應的演算法，在書的p133到p134之間。可以看到 這個對應不是一一對應的，主機還是要對多播數據進行過濾。
--
TCP
TCP和UDP處在同一層---運輸層，但是TCP和UDP最不同的地方是，TCP提供了一種可靠的數據傳輸服務，TCP是面向連接的，也就是說，利用TCP通信的兩台主機首先要經歷一個「撥打電話」的過程，等到通信准備結束才開始傳輸數據，最後結束通話。所以TCP要比UDP可靠的多，UDP是把數據直接發出去，而不管對方是不是在收信，就算是UDP無法送達，也不會產生ICMP差錯報文，這一經時重申了很多遍了。
把TCP保證可靠性的簡單工作原理:
應用數據被分割成TCP認為最適合發送的數據塊。這和UDP完全不同，應用程序產生的 數據報長度將保持不變。由TCP傳遞給IP的信息單位稱為報文段或段
當TCP發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能 及時收到一個確認，將重發這個報文段.
當TCP收到發自TCP連接另一端的數據，它將發送一個確認。這個確認不是立即發送，通常將推遲幾分之一秒.
TCP將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸 過程中的任何變化。如果收到段的檢驗和有差錯， T P將丟棄這個報文段和不確認收到此報文段（希望發端超時並重發）。
既然TCP報文段作為IP數據報來傳輸，而IP數據報的到達可能會失序，因此TCP報文段 的到達也可能會失序。如果必要， TCP將對收到的數據進行重新排序，將收到的數據以正確的順序交給應用層。
TCP還能提供流量控制。TCP連接的每一方都有固定大小的緩沖空間。TCP的接收端只允許另一端發送接收端緩沖區所能接納的數據。這將防止較快主機致使較慢主機的緩沖區溢出。
從這段話中可以看到，TCP中保持可靠性的方式就是超時重發，這是有道理的，雖然TCP也可以用各種各樣的ICMP報文來處理這些，但是這也不是可靠的，最可靠的方式就是只要不得到確認，就重新發送數據報，直到得到對方的確認為止。
TCP的首部和UDP首部一樣，都有發送埠號和接收埠號。但是顯然，TCP的首部信息要比UDP的多，可以看到，TCP協議提供了發送和確認所需要的所有必要的信息。可以想像一個TCP數據的發送應該是如下的一個過程。
雙方建立連接
發送方給接受方TCP數據報，然後等待對方的確認TCP數據報，如果沒有，就重新發，如果有，就發送下一個數據報。
接受方等待發送方的數據報，如果得到數據報並檢驗無誤，就發送ACK(確認)數據報，並等待下一個TCP數據報的到來。直到接收到FIN(發送完成數據報)
中止連接
可以想見，為了建立一個TCP連接，系統可能會建立一個新的進程（最差也是一個線程），來進行數據的傳送
--
TCP協議
TCP是一個面向連接的協議，在發送輸送之前 ，雙方需要確定連接。而且，發送的數據可以進行TCP層的分片處理。
TCP連接的建立過程 ，可以看成是三次握手 。而連接的中斷可以看成四次握手 。
1.連接的建立
在建立連接的時候，客戶端首先向伺服器申請打開某一個埠(用SYN段等於1的TCP報文)，然後伺服器端發回一個ACK報文通知客戶端請求報文收到，客戶端收到確認報文以後再次發出確認報文確認剛才伺服器端發出的確認報文（繞口么），至此，連接的建立完成。這就叫做三次握手。如果打算讓雙方都做好准備的話，一定要發送三次報文，而且只需要三次報文就可以了。
可以想見，如果再加上TCP的超時重傳機制，那麼TCP就完全可以保證一個數據包被送到目的地。
2.結束連接
TCP有一個特別的概念叫做half-close，這個概念是說，TCP的連接是全雙工（可以同時發送和接收）連接，因此在關閉連接的時候，必須關閉傳和送兩個方向上的連接。客戶機給伺服器一個FIN為1的TCP報文，然後伺服器返回給客戶端一個確認ACK報文，並且發送一個FIN報文，當客戶機回復ACK報文後（四次握手），連接就結束了。
3.最大報文長度
在建立連接的時候，通信的雙方要互相確認對方的最大報文長度(MSS)，以便通信。一般這個SYN長度是MTU減去固定IP首部和TCP首部長度。對於一個乙太網，一般可以達到1460位元組。當然如果對於非本地的IP，這個MSS可能就只有536位元組，而且，如果中間的傳輸網路的MSS更加的小的話，這個值還會變得更小。
4.客戶端應用程序的狀態遷移圖
客戶端的狀態可以用如下的流程來表示：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
以上流程是在程序正常的情況下應該有的流程，從書中的圖中可以看到，在建立連接時，當客戶端收到SYN報文的ACK以後，客戶端就打開了數據交互地連接。而結束連接則通常是客戶端主動結束的，客戶端結束應用程序以後，需要經歷FIN_WAIT_1，FIN_WAIT_2等狀態，這些狀態的遷移就是前面提到的結束連接的四次握手。
5.伺服器的狀態遷移圖
伺服器的狀態可以用如下的流程來表示：
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
在建立連接的時候，伺服器端是在第三次握手之後才進入數據交互狀態，而關閉連接則是在關閉連接的第二次握手以後（注意不是第四次）。而關閉以後還要等待客戶端給出最後的ACK包才能進入初始的狀態。
6.TCP伺服器設計
前面曾經講述過UDP的伺服器設計，可以發現UDP的伺服器完全不需要所謂的並發機制，它只要建立一個數據輸入隊列就可以。但是TCP不同，TCP伺服器對於每一個連接都需要建立一個獨立的進程（或者是輕量級的，線程），來保證對話的獨立性。所以TCP伺服器是並發的。而且TCP還需要配備一個呼入連接請求隊列（UDP伺服器也同樣不需要），來為每一個連接請求建立對話進程，這也就是為什麼各種TCP伺服器都有一個最大連接數的原因。而根據源主機的IP和埠號碼，伺服器可以很輕松的區別出不同的會話，來進行數據的分發。
TCP的交互數據流
對於交互性要求比較高的應用，TCP給出兩個策略來提高發送效率和減低網路負擔：（1）捎帶ACK。(2)Nagle演算法（一次盡量多的發數據）
捎帶ACK的發送方式
這個策略是說，當主機收到遠程主機的TCP數據報之後，通常不馬上發送ACK數據報，而是等上一個短暫的時間，如果這段時間裡面主機還有發送到遠程主機的TCP數據報，那麼就把這個ACK數據報「捎帶」著發送出去，把本來兩個TCP數據報整合成一個發送。一般的，這個時間是200ms。可以明顯地看到這個策略可以把TCP數據報的利用率提高很多。
Nagle演算法
上過bbs的人應該都會有感受，就是在網路慢的時候發貼，有時鍵入一串字元串以後，經過一段時間，客戶端「發瘋」一樣突然回顯出很多內容，就好像數據一下子傳過來了一樣，這就是Nagle演算法的作用。
Nagle演算法是說，當主機A給主機B發送了一個TCP數據報並進入等待主機B的ACK數據報的狀態時，TCP的輸出緩沖區裡面只能有一個TCP數據報，並且，這個數據報不斷地收集後來的數據，整合成一個大的數據報，等到B主機的ACK包一到，就把這些數據「一股腦」的發送出去。雖然這樣的描述有些不準確，但還算形象和易於理解，我們同樣可以體會到這個策略對於低減網路負擔的好處。
在編寫插口程序的時候，可以通過TCP_NODELAY來關閉這個演算法。並且，使用這個演算法看情況的，比如基於TCP的X窗口協議，如果處理滑鼠事件時還是用這個演算法，那麼「延遲」可就非常大了。
2.TCP的成塊數據流
對於FTP這樣對於數據吞吐量有較高要求的要求，將總是希望每次盡量多的發送數據到對方主機，就算是有點「延遲」也無所謂。TCP也提供了一整套的策略來支持這樣的需求。TCP協議中有16個bit表示「窗口」的大小，這是這些策略的核心。
2.1.傳輸數據時ACK的問題
在解釋滑動窗口前，需要看看ACK的應答策略，一般來說，發送端發送一個TCP數據報，那麼接收端就應該發送一個ACK數據報。但是事實上卻不是這樣，發送端將會連續發送數據盡量填滿接受方的緩沖區，而接受方對這些數據只要發送一個ACK報文來回應就可以了，這就是ACK的累積特性，這個特性大大減少了發送端和接收端的負擔。
2.2.滑動窗口
滑動窗口本質上是描述接受方的TCP數據報緩沖區大小的數據，發送方根據這個數據來計算自己最多能發送多長的數據。如果發送方收到接受方的窗口大小為0的TCP數據報，那麼發送方將停止發送數據，等到接受方發送窗口大小不為0的數據報的到來。
2.3.數據擁塞
上面的策略用於區域網內傳輸還可以，但是用在廣域網中就可能會出現問題，最大的問題就是當傳輸時出現了瓶頸（比如說一定要經過一個slip低速鏈路）所產生的大量數據堵塞問題（擁塞），為了解決這個問題，TCP發送方需要確認連接雙方的線路的數據最大吞吐量是多少。這，就是所謂的擁塞窗口。
擁塞窗口的原理很簡單，TCP發送方首先發送一個數據報，然後等待對方的回應，得到回應後就把這個窗口的大小加倍，然後連續發送兩個數據報，等到對方回應以後，再把這個窗口加倍（先是2的指數倍，到一定程度後就變成現行增長，這就是所謂的慢啟動），發送更多的數據報，直到出現超時錯誤，這樣，發送端就了解到了通信雙方的線路承載能力，也就確定了擁塞窗口的大小，發送方就用這個擁塞窗口的大小發送數據。要觀察這個現象是非常容易的，我們一般在下載數據的時候，速度都是慢慢「沖起來的」
--
TCP的超時和重傳
超時重傳是TCP協議保證數據可靠性的另一個重要機制，其原理是在發送某一個數據以後就開啟一個計時器，在一定時間內如果沒有得到發送的數據報的ACK報文，那麼就重新發送數據，直到發送成功為止。
超時
超時時間的計算是超時的核心部分，TCP要求這個演算法能大致估計出當前的網路狀況，雖然這確實很困難。要求精確的原因有兩個：(1)定時長久會造成網路利用率不高。(2)定時太短會造成多次重傳，使得網路阻塞。所以，書中給出了一套經驗公式，和其他的保證計時器准確的措施。
計時器的使用
一個連接中，有且僅有一個測量定時器被使用。也就是說，如果TCP連續發出3組數據，只有一組數據會被測量。
ACK數據報不會被測量，原因很簡單，沒有ACK的ACK回應可以供結束定時器測量。
重傳
前面曾經提到過，數據在傳輸的時候不能只使用一個窗口協議，我們還需要有一個擁塞窗口來控制數據的流量，使得數據不會一下子都跑到網路中引起「擁塞」。也曾經提到過，擁塞窗口最初使用指數增長的速度來增加自身的窗口，直到發生超時重傳，再進行一次微調。但是沒有提到，如何進行微調，擁塞避免演算法和慢啟動門限就是為此而生。
所謂的慢啟動門限就是說，當擁塞窗口超過這個門限的時候，就使用擁塞避免演算法，而在門限以內就採用慢啟動演算法。所以這個標准才叫做門限，通常，擁塞窗口記做cwnd，慢啟動門限記做ssthresh。下面我們來看看擁塞避免和慢啟動是怎麼一起工作的
演算法概要
對一個給定的連接，初始化cwnd為1個報文段，ssthresh為65535個位元組。
TCP輸出常式的輸出不能超過cwnd和接收方通告窗口的大小。擁塞避免是發送方使用 的流量控制，而通告窗口則是接收方進行的流量控制。前者是發送方感受到的網路擁塞的估 計，而後者則與接收方在該連接上的可用緩存大小有關。
當擁塞發生時（超時或收到重復確認），ssthresh被設置為當前窗口大小的一半（cwnd 和接收方通告窗口大小的最小值，但最少為2個報文段）。此外，如果是超時引起了擁塞，則 cwnd被設置為1個報文段（這就是慢啟動）。
當新的數據被對方確認時，就增加cwnd，但增加的方法依賴於我們是否正在進行慢啟 動或擁塞避免。如果cwnd小於或等於ssthresh，則正在進行慢啟動，否則正在進行擁塞避免。 慢啟動一直持續到我們回到當擁塞發生時所處位置的半時候才停止（因為我們記錄了在步驟2 中給我們製造麻煩的窗口大小的一半），然後轉為執行擁塞避免。
快速重傳和快速恢復演算法
這是數據丟包的情況下給出的一種修補機制。一般來說，重傳發生在超時之後，但是如果發送端接受到3個以上的重復ACK的情況下，就應該意識到，數據丟了，需要重新傳遞。這個機制是不需要等到重傳定時器溢出的，所以叫做快速重傳，而重新傳遞以後，因為走的不是慢啟動而是擁塞避免演算法，所以這又叫做快速恢復演算法。流程如下：
當收到第3個重復的ACK時，將ssthresh設置為當前擁塞窗口cwnd的一半。重傳丟失的 報文段。設置cwnd為ssthresh加上3倍的報文段大小。
每次收到另一個重復的ACK時， cwnd增加1個報文段大小並發送1個分組（如果新的 cwnd允許發送）。
當下一個確認新數據的ACK到達時，設置cwnd為ssthresh（在第1步中設置的值）。這個 ACK應該是在進行重傳後的一個往返時間內對步驟1中重傳的確認。另外，這個ACK也應該 是對丟失的分組和收到的第1個重復的ACK之間的所有中間報文段的確認。這一步採用的是擁 塞避免，因為當分組丟失時我們將當前的速率減半。
TCP的其它定時器
堅持定時器
用於防止通告窗口為0以後雙方互相等待死鎖的情況
堅持定時器的原理是簡單的，當TCP伺服器收到了客戶端的0滑動窗口報文的時候，就啟動一個定時器來計時，並在定時器溢出的時候向向客戶端查詢窗口是否已經增大，如果得到非零的窗口就重新開始發送數據，如果得到0窗口就再開一個新的定時器准備下一次查詢。通過觀察可以得知，TCP的堅持定時器使用1，2，4，8，16……64秒這樣的普通指數退避序列來作為每一次的溢出時間。
2.保活定時器
保活定時器更加的簡單，還記得FTP或者Http伺服器都有Sesstion Time機制么？因為TCP是面向連接的，所以就會出現只連接不傳送數據的「半開放連接」，伺服器當然要檢測到這種連接並且在某些情況下釋放這種連接，這就是保活定時器的作用。其時限根據伺服器的實現不同而不通。另外要提到的是，當其中一端如果崩潰並重新啟動的情況下，如果收到該端「前生」的保活探察，則要發送一個RST數據報文幫助另一端結束連接。

Ⅳ 設置tcp的哪個socket參數會影響了nagle演算法

TCP_NODELAY

Ⅳ 簡述在tcp/ip體系中，流量控制和擁塞控制的不同

1. 利用滑動窗口實現流量控制
如果發送方把數據發送得過快，接收方可能會來不及接收，這就會造成數據的丟失。所謂流量控制就是讓發送方的發送速率不要太快，要讓接收方來得及接收。
利用滑動窗口機制可以很方便地在TCP連接上實現對發送方的流量控制。
設A向B發送數據。在連接建立時，B告訴了A：「我的接收窗口是 rwnd = 400 」(這里的 rwnd 表示 receiver window) 。因此，發送方的發送窗口不能超過接收方給出的接收窗口的數值。請注意，TCP的窗口單位是位元組，不是報文段。TCP連接建立時的窗口協商過程在圖中沒有顯示出來。再設每一個報文段為100位元組長，而數據報文段序號的初始值設為1。大寫ACK表示首部中的確認位ACK，小寫ack表示確認欄位的值ack。

從圖中可以看出，B進行了三次流量控制。第一次把窗口減少到 rwnd = 300 ，第二次又減到了 rwnd = 100 ，最後減到 rwnd = 0 ，即不允許發送方再發送數據了。這種使發送方暫停發送的狀態將持續到主機B重新發出一個新的窗口值為止。B向A發送的三個報文段都設置了 ACK = 1 ，只有在ACK=1時確認號欄位才有意義。
TCP為每一個連接設有一個持續計時器(persistence timer)。只要TCP連接的一方收到對方的零窗口通知，就啟動持續計時器。若持續計時器設置的時間到期，就發送一個零窗口控測報文段（攜1位元組的數據），那麼收到這個報文段的一方就重新設置持續計時器。
2. 必須考慮傳輸速率
可以用不同的機制來控制TCP報文段的發送時機。如： <1>. TCP維持一個變數，它等於最大報文段長度MSS。只要緩存中存放的數據達到MSS位元組時，就組裝成一個TCP報文段發送出去。<2>. 由發送方的應用進程指明要求發送報文段，即TCP支持的推送( push )操作。<3>. 發送方的一個計時器期限到了，這時就把已有的緩存數據裝入報文段(但長度不能超過MSS)發送出去。
Nagle演算法：若發送應用進程把要發送的數據逐個位元組地送到TCP的發送緩存，則發送方就把第一個數據位元組先發送出去，把後面到達的數據位元組都緩存起來。當發送方接收對第一個數據字元的確認後，再把發送緩存中的所有數據組裝成一個報文段再發送出去，同時繼續對隨後到達的數據進行緩存。只有在收到對前一個報文段的確認後才繼續發送下一個報文段。當數據到達較快而網路速率較慢時，用這樣的方法可明顯地減少所用的網路帶寬。Nagle演算法還規定：當到達的數據已達到 發送窗口大小的一半或已達到報文段的最大長度時，就立即發送一個報文段。
另，糊塗窗口綜合證： TCP接收方的緩存已滿，而互動式的應用進程一次只從接收緩存中讀取1位元組（這樣就使接收緩存空間僅騰出1位元組），然後向發送方發送確認，並把窗口設置為1個位元組（但發送的數據報為40位元組的的話）。接收，發送方又發來1個位元組的數據（發送方的IP數據報是41位元組）。接收方發回確認，仍然將窗口設置為1個位元組。這樣，網路的效率很低。要解決這個問題，可讓接收方等待一段時間，使得或者接收緩存已有足夠空間容納一個最長的報文段，或者等到接收方緩存已有一半空閑的空間。只要出現這兩種情況，接收方就發回確認報文，並向發送方通知當前的窗口大小。此外，發送方也不要發送太小的報文段，而是把數據報積累成足夠大的報文段，或達到接收方緩存的空間的一半大小。

TCP的擁塞控制
1. 擁塞：即對資源的需求超過了可用的資源。若網路中許多資源同時供應不足，網路的性能就要明顯變壞，整個網路的吞吐量隨之負荷的增大而下降。
擁塞控制：防止過多的數據注入到網路中，這樣可以使網路中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提：網路能夠承受現有的網路負荷。擁塞控制是一個全局性的過程，涉及到所有的主機、路由器，以及與降低網路傳輸性能有關的所有因素。
流量控制：指點對點通信量的控制，是端到端正的問題。流量控制所要做的就是抑制發送端發送數據的速率，以便使接收端來得及接收。
擁塞控制代價：需要獲得網路內部流量分布的信息。在實施擁塞控制之前，還需要在結點之間交換信息和各種命令，以便選擇控制的策略和實施控制。這樣就產生了額外的開銷。擁塞控制還需要將一些資源分配給各個用戶單獨使用，使得網路資源不能更好地實現共享。
2. 幾種擁塞控制方法
慢開始( slow-start )、擁塞避免( congestion avoidance )、快重傳( fast retransmit )和快恢復( fast recovery )。
2.1 慢開始和擁塞避免
發送方維持一個擁塞窗口 cwnd ( congestion window )的狀態變數。擁塞窗口的大小取決於網路的擁塞程度，並且動態地在變化。發送方讓自己的發送窗口等於擁塞。
發送方控制擁塞窗口的原則是：只要網路沒有出現擁塞，擁塞窗口就再增大一些，以便把更多的分組發送出去。但只要網路出現擁塞，擁塞窗口就減小一些，以減少注入到網路中的分組數。
慢開始演算法：當主機開始發送數據時，如果立即所大量數據位元組注入到網路，那麼就有可能引起網路擁塞，因為現在並不清楚網路的負荷情況。因此，較好的方法是先探測一下，即由小到大逐漸增大發送窗口，也就是說，由小到大逐漸增大擁塞窗口數值。通常在剛剛開始發送報文段時，先把擁塞窗口 cwnd 設置為一個最大報文段MSS的數值。而在每收到一個對新的報文段的確認後，把擁塞窗口增加至多一個MSS的數值。用這樣的方法逐步增大發送方的擁塞窗口 cwnd ，可以使分組注入到網路的速率更加合理。

每經過一個傳輸輪次，擁塞窗口 cwnd 就加倍。一個傳輸輪次所經歷的時間其實就是往返時間RTT。不過「傳輸輪次」更加強調：把擁塞窗口cwnd所允許發送的報文段都連續發送出去，並收到了對已發送的最後一個位元組的確認。
另，慢開始的「慢」並不是指cwnd的增長速率慢，而是指在TCP開始發送報文段時先設置cwnd=1，使得發送方在開始時只發送一個報文段（目的是試探一下網路的擁塞情況），然後再逐漸增大cwnd。
為了防止擁塞窗口cwnd增長過大引起網路擁塞，還需要設置一個慢開始門限ssthresh狀態變數（如何設置ssthresh）。慢開始門限ssthresh的用法如下：
當 cwnd < ssthresh 時，使用上述的慢開始演算法。
當 cwnd > ssthresh 時，停止使用慢開始演算法而改用擁塞避免演算法。
當 cwnd = ssthresh 時，既可使用慢開始演算法，也可使用擁塞控制避免演算法。
擁塞避免演算法：讓擁塞窗口cwnd緩慢地增大，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口cwnd按線性規律緩慢增長，比慢開始演算法的擁塞窗口增長速率緩慢得多。
無論在慢開始階段還是在擁塞避免階段，只要發送方判斷網路出現擁塞（其根據就是沒有收到確認），就要把慢開始門限ssthresh設置為出現擁塞時的發送方窗口值的一半（但不能小於2）。然後把擁塞窗口cwnd重新設置為1，執行慢開始演算法。這樣做的目的就是要迅速減少主機發送到網路中的分組數，使得發生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。
如下圖，用具體數值說明了上述擁塞控制的過程。現在發送窗口的大小和擁塞窗口一樣大。

<1>. 當TCP連接進行初始化時，把擁塞窗口cwnd置為1。前面已說過，為了便於理解，圖中的窗口單位不使用位元組而使用報文段的個數。慢開始門限的初始值設置為16個報文段，即 cwnd = 16 。
<2>. 在執行慢開始演算法時，擁塞窗口 cwnd 的初始值為1。以後發送方每收到一個對新報文段的確認ACK，就把擁塞窗口值另1，然後開始下一輪的傳輸（圖中橫坐標為傳輸輪次）。因此擁塞窗口cwnd隨著傳輸輪次按指數規律增長。當擁塞窗口cwnd增長到慢開始門限值ssthresh時（即當cwnd=16時），就改為執行擁塞控制演算法，擁塞窗口按線性規律增長。
<3>. 假定擁塞窗口的數值增長到24時，網路出現超時（這很可能就是網路發生擁塞了）。更新後的ssthresh值變為12（即變為出現超時時的擁塞窗口數值24的一半），擁塞窗口再重新設置為1，並執行慢開始演算法。當cwnd=ssthresh=12時改為執行擁塞避免演算法，擁塞窗口按線性規律增長，每經過一個往返時間增加一個MSS的大小。
強調：「擁塞避免」並非指完全能夠避免了擁塞。利用以上的措施要完全避免網路擁塞還是不可能的。「擁塞避免」是說在擁塞避免階段將擁塞窗口控制為按線性規律增長，使網路比較不容易出現擁塞。

Ⅵ 在tcp協議中，發送方的窗口大小是由哪些因素決定的

在TCP協議中，發送方的窗口大小是由（接收方允許的窗口和信道窗口）決定的。

TCP是網際網路中的傳輸層協議，使用三次握手協議建立連接。當主動方發出SYN連接請求後，等待對方回答SYN+ACK，並最終對對方的 SYN 執行 ACK 確認。

這種建立連接的方法可以防止產生錯誤的連接，TCP使用的流量控制協議是可變大小的滑動窗口協議。

(6)tcpnagle演算法擴展閱讀：

TCP將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP將丟棄這個報文段和不確認收到此報文段（希望發端超時並重發）。

既然TCP報文段作為IP數據報來傳輸，而IP數據報的到達可能會失序，因此TCP報文段的到達也可能會失序。如果必要，TCP將對收到的數據進行重新排序，將收到的數據以正確的順序交給應用層。

Ⅶ TCP協議是如何實現差錯控制和流量控制

流量控制：
1、流量控制是管理兩端的流量，以免會產生發送過塊導致收端溢出，或者因收端處理太快而浪費時間的狀態。用的是：滑動窗口，以位元組為單位

2、窗口有3種動作：展開（右邊向右），合攏（左邊向右），收縮（右邊向左）這三種動作受接收端的控制。
合攏：表示已經收到相應位元組的確認了
展開：表示允許緩存發送更多的位元組
收縮（非常不希望出現的，某些實現是禁止的）：表示本來可以發送的，現在不能發送；但是如果收縮的是那些已經發出的，就會有問題；為了避免，收端會等待到緩存中有更多緩存空間時才進行通信。
發端窗口的大小取決於收端的窗口大小rwnd（TCP報文的窗口大小欄位）和擁塞窗口大小cwnd（見擁塞控制）
發端窗口大小 = min{ rwnd , cwnd };

3、關閉窗口：窗口縮回有個例外，就是發送rwnd=0表示暫時不願意接收數據。這種情況下，發端不是把窗口收縮，二是停止發送數據。（為了比避免死鎖，會用一些探測報定時發送試探，見定時器一節）

4、問題：某些時候，由於發端或收端的數據很慢，會引起大量的1位元組數據痛惜，浪費很多資源。
（1）、發端的進程產生數據很慢時候，時不時的來個1位元組數據，那麼TCP就會1位元組1位元組的發送，效率很低。
解決方法（Nagle演算法）：
a、將第一塊數據發出去
b、然後等到發送緩存有足夠多的數據（最大報文段長度），或者等到收端確認的ACK時再發送數據。
c、重復b的過程
（2）、收端進程由於消耗數據很慢，所以可能會有這么一種情況，收端會發送其窗口大小為1的信息，然後有是1位元組的傳輸
解決辦法（2種）
a、Clark方法：在接收緩存的一半變空，或者有足夠空間放最大報文長度之前，宣告接收窗口大小為0
b、推遲確認：在對收到的報文段確認之前等待到足夠的接收緩存，或者等待到一個時間段（現在一般定義500ms）

擁塞控制：
1、如果網路上的負載（發送到網路上的分組數）大於網路上的容量（網路同時能處理的分組數），就可能引起擁塞，判斷網路擁塞的兩個因素：延時和吞吐量。擁塞控制機制是：開環（預防）和閉環（消除）（見網路原理相關書籍，略）
tcp處理擁塞的三種策略：慢啟動（指數增大），擁塞避免（加法增大），擁塞檢測（除2減少，或叫做乘法減少）

2、慢啟動：指數增大
/* ssthresh是慢開始門限，slow start threshold表示一個上限，一般的實現為65535B */
cwnd = 1;(1表示一個MSS報文段，不是一個位元組)
while （ cwnd < ssthresh )
if（ 發出的報文段確認 ）
cwd *= 2;

3、擁塞避免：加法增大
當到達ssthresh之後，就是加法階段了，每收到一個確認，cwd += 1；

4、擁塞檢測：乘法減少（除2減少）
當報文需要重傳時，說明擁塞可能發生了，由於重傳有2種情況，所以也分兩種處理
（1）、由於超時重傳，這是擁塞的可能性比較大，如下做強反映調整
a、 ssthresh /= 2;
b、 cwnd = 1；
重新慢啟動過程
（2）、由於收到3個重復的ACK的重傳，採取弱反映：
a、ssthresh /= 2;
b、cwnd = ssthresh;
c、開始擁塞避免過程

差錯控制：
1、TCP必須保證數據：按序，沒有差錯，沒有部分丟失，沒有重復的交給應用層。方法就是：校驗和，確認，超時重傳

2、校驗和：和UDP的做法一樣，也要偽首部，和UDP不同的是這個功能在TCP中是必須的

3、確認：ACK的確認機制（下面是一些原則）
a、ACK報文不需要確認，也不消耗序號
b、當一端發送數據時，盡量包含捎帶確認。
c、收端推遲發送ACK報文段，如果僅有一個未確認的按序報文段；延遲到500ms，或者有第二個報文段接收時（轉d），或者有數據要發送時（轉b）
d、任何時候,不能有兩個（以上）未確認的報文段（就是說如果收端有兩個未確認的按序報文段，就馬上發送ACK報文段進行確認）
e、當收到一個序號比期望序號還大的報文段時，馬上發送ACK，讓發端進行快重傳
f、收到重復的報文段，就立即發送確認(解決ACK丟失問題)
g、丟失的報文段到達，發送確認，表示已經收到了丟失的報文

4、確認類型
累計確認：收端忽略掉所有失序報文，告知發端他期待下一個收到的序號，叫做肯定累計ACK。肯定是說：丟棄的，丟失的，重復的都不報告。
選擇確認（SACK）：在某些新TCP實現裡面實現了這個東西，報告失序和重復的數據，作偽TCP首部選項欄位的一部分。

5、重傳（兩種情況） ： 重傳定時器時間到，或者 發端收到重復的三個ACK（快重傳）

給分兒，採納

Ⅷ tcp/ip協議 =》Nagle Algorithm 有誰比較 了解以下演算法

Nagle Algorithm 就是發小數據前先稍等一下， 這期間如果有新數據就一起發掉。 主要目的就是減少發包的數量避免擁堵了

Ⅸ win10優化電腦游戲性能

win10系統已經發布一段時間了，穩定性也比較好，不過有時候win10系統玩游戲總一卡一卡，不管是什麼游戲都一樣，有什麼辦法優化一下，讓游戲運行速度更加流暢？方法當然有的，這里給大家准備win10提高游戲性能的四種優化方法。

一. 關閉nagle演算法

很多人對於Nagle演算法並不了解，簡單來說，這是TCP協議里的一套演算法

可以將數據小包統一打包成為一堆再發送，減少傳輸次數，主要用來提高帶寬利用率避免網路擁堵。

不過Nagle也是一柄雙刃劍，它的最大問題就是導致某些在線操作延遲過高，進而導致網游卡頓。

1. 按下快捷鍵Win+R，調出「運行」對話框，輸入「regedit」進入注冊表編輯器;

2. 將下列地址粘貼到注冊表編輯器的地址欄中：計算機HKEY_LOCAL_;

和之前系統相比，Win10在游戲方面其實更強。特別是一些新技術的加入

讓很多新游戲多了更多可發揮的空間。不過要是你比較青睞老游戲

或者電腦的配置原本不高，就需要對Win10進行一番調教了。

以上和大家分享win10玩游戲總一卡一卡的四種優化方法，趕緊設置試試看！希望對你有所幫助