tcp學習記錄(摘自tcp/ip卷一)
tcp的 time_wait 狀態
tcp要求，首先發出 fin 的一端，在通訊雙方都完全關閉連線之後，仍然要保持在 time_wait 狀態直至兩倍的報文段最大生存時間(msl)。msl 的建議值是120秒，也即處於 time_wait 狀態要達到4分鐘。當連線處於 time_wait 狀態時，同一連線(即客戶i p位址和埠號，以及伺服器i p位址和埠號這4個值相同)不能重複開啟。
客戶端首先發出 fin，這稱為主動關閉，因而 time_wait 狀態出現在客戶端。在這個狀態延續期內， tcp 要為這個已經關閉的連線保留一定的狀態資訊，以便能正確處理那些在網路中延遲一段時間、在連線關閉之後到達的報文段。同樣，如果最後乙個 ack 丟失了，伺服器將重傳 fin，使客戶端重傳最後的 ack。由於客戶程序主動關閉連線(即由客戶程序首先發出fin )，因而在客戶收到伺服器的 fin 後還要在 time_wait 狀態滯留大約240秒.
time_wait狀態和16位元tcp埠號這兩者結合起來限制了兩台主機之間的最大事務速率。例如，如果同一臺客戶主機要不斷地和同一臺伺服器主機進行事務通訊，那麼它要麼每完成一次事務後等待240秒才開始下乙個事務，要麼為緊接著的事務選擇另外乙個埠號。但每240秒的時間內至多只能有64512個埠(65535減去1023個知名埠)可用，從而每秒最多也就只能處理268個事務。在rtt值大約為 1~3ms 的區域網上，實際上可能會超過這個速率.
收到乙個 fin 只意味著在這一方向上沒有資料流動。乙個 tcp 連線在收到乙個 fin 後仍能傳送資料。而這對利用半關閉的應用來說是可能的,首先進行關閉的一方（即傳送第乙個fin）將執行主動關閉，而另一方（收到這個fin ）執行被動關閉。通常一方完成主動關閉而另一方完成被動關閉
tcp的半關閉
tcp提供了連線的一端在結束它的傳送後還能接收來自另一端資料的能力
time_wait 狀態也稱為2msl 等待狀態。每個具體t c p實現必須選擇乙個報文段最大生存時間msl（maximum segment lifetime）。它是任何報文段被丟棄前在網路內的最長時間。我們知道這個時間是有限的，因為tcp報文段以 i p 資料報在網路內傳輸，而i p資料報則有限制其生存時間的 ttl 字段。
客戶執行主動關閉並進入 time_wait 是正常的。伺服器通常執行被動關閉，不會進入 time_wait 狀態。這暗示如果我們終止乙個客戶程式，並立即重新啟動這個客戶程式，則這個新客戶程式將不能重用相同的本地埠。
在 fin_wait2 狀態我們已經發出了 fin ，並且另一端也已對它進行確認。除非我們在實行半關閉，否則將等待另一端的應用層意識到它已收到乙個檔案結束符說明，並向我們發乙個 fin 來關閉另一方向的連線。只有當另一端的程序完成這個關閉，我們這端才會從
fin_wait2 狀態進入 time_wait 狀態。這意味著我們這端可能永遠保持這個狀態。另一端也將處於 close_wait 狀態，並一直保持這個狀態直到應用層決定進行關閉。
檢測半開啟連線
如果一方已經關閉或異常終止連線而另一方卻還不知道，我們將這樣的 tcp 連線稱為半開啟（half- open）的。任何一端的主機異常都可能導致發生這種情況。只要不打算在半開啟連線上傳輸資料，仍處於連線狀態的一方就不會檢測另一方已經出現異常。由於伺服器的 tcp 已經重新啟動，它將丟失復位前連線的所有資訊，因此它不知道資料報文段中提到的連線。 tcp 的處理原則是接收方以復位作為應答。
同時開啟
兩個應用程式同時彼此執行主動開啟的情況是可能的，儘管發生的可能性極小。每一方必須傳送乙個syn，且這些 syn 必須傳遞給對方。這需要每一方使用乙個對方熟知的埠作為本地埠。這又稱為同時開啟（ simultaneous open）tcp是特意設計為了可以處理同時開啟，對於同時開啟它僅建立一條連線而不是兩條連線（其他的協議族，最突出的是 osi 運輸層，在這種情況下將建立兩條連線而不是一條連線）
異常終止乙個連線
異常終止乙個連線對應用程式來說有兩個優點：（1）丟棄任何待發資料並立即傳送復位報文段；（2）rst 的接收方會區分另一端執行的是異常關閉還是正常關閉。應用程式使用的 api 必須提供產生異常關閉而不是正常關閉的手段。
產生復位的一種常見情況是當連線請求到達時，目的埠沒有程序正在聽。
同時關閉
當應用層發出關閉命令時，兩端均從 established 變為 fin_wait_1。這將導致雙方各傳送乙個 fin，兩個 fin 經過網路傳送後分別到達另一端。收到 fin 後，狀態由 fin_wait_1 變遷到 closing，並傳送最後的a c k。當收到最後的 ack 時，狀態變化為time_wait。
tcp伺服器端口號
tcp使用由本地位址和遠端位址組成的4元組：目的ip位址、目的埠號、源ip位址和源埠號來處理傳入的多個連線請求。tcp僅通過目的埠號無法確定那個程序接收了乙個連線請求。另外，在三個使用埠23的程序中，只有處於 listen 的程序能夠接收新的連線請求。處於 established 的程序將不能接收 syn 報文段，而處於 listen 的程序將不能接收資料報文段。
乙個tcp連線由乙個4元組唯一確定：本地ip位址、本地埠號、遠端ip位址和遠端埠號。
呼入連線請求佇列
1) 乙個併發伺服器呼叫乙個新的程序來處理每個客戶請求，因此處於被動連線請求的伺服器應該始終準備處理下乙個呼入的連線請求。那正是使用併發伺服器的根本原因。但仍有可能出現當伺服器在建立乙個新的程序時，或作業系統正忙於處理優先順序更高的程序時，到達多個連線請求。當伺服器正處於忙時， tcp是如何處理這些呼入的連線請求？正等待連線請求的一端有乙個固定長度的連線佇列，該佇列中的連線已被 tcp 接受（即三次握手已經完成），但還沒有被應用層所接受。注意區分 tcp 接受乙個連線是將其放入這個佇列，而應用層接受連線是將其從該佇列中移出。
2) 應用層將指明該佇列的最大長度，這個值通常稱為積壓值( backlog )。它的取值範圍是0-5之間的整數，包括0和5（大多數的應用程式都將這個值設定為5），當乙個連線請求（即syn）到達時，tcp 使用乙個演算法，根據當前連線佇列中的連線數來確定是否接收這個連線。我們期望應用層說明的積壓值為這一端點所能允許接受連線的最大數目，但情況不是那麼簡單，注意：積壓值說明的是tcp 監聽的端點已被tcp 接受而等待應用層接受的最大連線數。這個積壓值對系統所允許的最大連線數，或者併發伺服器所能併發處理的客戶數，並無影響。
3) 如果對於新的連線請求，該tcp監聽的端點的連線佇列中還有空間，tcp模組將對 syn 進行確認並完成連線的建立。但應用層只有在三次握手中的第三個報文段收到後才會知道這個新連線時。另外，當客戶程序的主動開啟成功但伺服器的應用層還不知道這個新的連線時，它可能會認為伺服器程序已經準備好接收資料了（如果發生這種情況，伺服器的tcp僅將接收的資料放入緩衝佇列)。
4) 如果對於新的連線請求，連線佇列中已沒有空間， tcp將不理會收到的syn。也不發回任何報文段（即不發回rst）。如果應用層不能及時接受已被tcp接受的連線，這些連線可能佔滿整個連線佇列，客戶的主動開啟最終將超時。
期望接收連線佇列按先進先出順序傳遞給應用層。如tcp接受了埠為1090和1091的連線，我們希望應用層先接受埠為1090的連線，然後再接受埠為1091的連線。但許多伯克利的tcp實現都出現按後進先出的傳遞順序，這個錯誤已存在了多年。當佇列已滿時，tcp將不理會傳入的syn，也不發回rst作為應答，因為這是乙個軟錯誤，而不是乙個硬錯誤。通常佇列已滿是由於應用程式或作業系統忙造成的，這樣可防止應用程式對傳入的連線進行服務。這個條件在乙個很短的時間內可以改變。但如果伺服器的tcp以系統復位作為響應，客戶程序的主動開啟將被廢棄（如果伺服器程式沒有啟動我們就會遇到）。由於不應答syn，伺服器程式迫使客戶tcp隨後重傳syn，以等待連線佇列有空間接受新的連線。
這種行為也意味著tcp伺服器無法使客戶程序的主動開啟失效。當乙個新的客戶連線傳遞給伺服器的應用程式時， tcp的三次握手就結束了，客戶的主動開啟已經完全成功。如果伺服器的應用程式此時看到客戶的i p位址和埠號，並決定是否為該客戶進行服務，伺服器所能做的就是關閉連線（傳送 fin），或者復位連線（傳送 rst）。無論哪種情況，客戶程序都認為一切正常，因為它的主動開啟已經完成，並且已經向伺服器程式傳送過請求。
學習《TCP IP詳解卷1 協議》 TCP
tcp 傳輸控制協議 儘管tcp和udp都使用相同的網路層 ip tcp卻向應用層提供與udp完全不同的服務。tcp提供一種面向連線的 可靠的位元組流服務。面向連線意味著兩個使用tcp的應用 通常是乙個客戶和乙個伺服器 在彼此交換資料之前必須先建立乙個tcp連線。tcp通過下列方式來提供可靠性 1....
TCP IP協議詳解卷1學習筆記 TCP協議
tcp協議 tcp首部 源埠號 目的埠號 位序號 位確認序號 首部長度 標誌位 視窗大小 檢驗和 緊急指標和其它選項。乙個ip位址和乙個埠號也成為乙個插口 socket 插口對可唯一確定網際網路中每個tcp連線的雙方。tcp連線的建立與終止 tcp是乙個面向連線的協議，無論哪方向另一方傳送資料之前，...
TCP IP詳解卷1協議攻擊記錄
書中很多章節提到了攻擊，記錄下 動態ip可能在精確度要求比較高的場合容易造成錯誤 通過wifi等網路非法或者其他途徑接入，如果做了什麼不允許的事情，ip位址擁有者將需要承擔責任。arp攻擊 偽造arp應答或者廣播報文，讓主機arp記錄有誤，或者通過arp 偽裝目的主機。以前更多的是通過設定ip的某些...