一、三次握手原理：
tcp握手協議
在tcp/ip協議中，tcp協議提供可靠的連線服務，採用三次握手建立乙個連線。
第一次握手：建立連線時，客戶端傳送syn包(syn=j)到伺服器，並進入syn_send狀態，等待伺服器確認； （客戶端問伺服器：你愛我嗎？）
第二次握手：伺服器收到syn包，必須確認客戶的syn（ack=j+1），同時自己也傳送乙個syn包（syn=k），即syn+ack包，此時伺服器進入syn_recv狀態；
（伺服器回答：我愛你，你也愛我嗎？）
第三次握手：客戶端收到伺服器的syn＋ack包，向伺服器傳送確認包ack(ack=k+1)，此包傳送完畢，客戶端和伺服器進入established狀態，完成三次握手。
（客戶端回答：我愛你，你也愛我，那我們結婚吧！（established））
完成三次握手，客戶端與伺服器開始傳送資料，在上述過程中，還有一些重要的概念：
未連線佇列：在三次握手協議中，伺服器維護乙個未連線佇列，該隊列為每個客戶端的syn包（syn=j）開設乙個條目，該條目表明伺服器已收到syn包，並向客戶發出確認，正在等待客戶的確認包。這些條目所標識的連線在伺服器處於syn_recv狀態，當伺服器收到客戶的確認包時，刪除該條目，伺服器進入established狀態。
backlog引數：表示未連線佇列的最大容納數目。
syn-ack 重傳次數 伺服器傳送完syn－ack包，如果未收到客戶確認包，伺服器進行首次重傳，等待一段時間仍未收到客戶確認包，進行第二次重傳，如果重傳次數超過系統規定的最大重傳次數，系統將該連線資訊從半連線佇列中刪除。注意，每次重傳等待的時間不一定相同。
二、四次揮手原理：
tcp的終止通過雙方的四次握手實現。發起終止的一方執行主動關閉，響應的另一方執行被動關閉。
發起方(client)更改狀態為fin_wait_1，關閉應用程式程序，發出乙個tcp的fin段；
接收方收到fin段，返回乙個帶確認序號的ack，同時向自己對應的程序傳送乙個檔案結束符eof，同時更改狀態為close_wait(server)，發起方接到ack後狀態更改為fin_wait_2(client)；
接收方關閉應用程式程序，更改狀態為last_ack(server)，並向對方發出乙個tcp的fin段；
發起方接到fin後狀態更改為time_wait(client)，並發出這個fin的ack確認。ack傳送成功後(2msl內)雙方tcp狀態變為closed。
我們不難看出上面的顯示的結果的意思。根據tcp協議，主動發起關閉的一方，會進入time_wait狀態(tcp實現必須可靠地終止連線的兩個方向(全雙工關閉))，持續2*msl(max segment lifetime)，預設為240秒.
第一次揮手：客戶端a傳送乙個fin，用來關閉客戶a到伺服器b的資料傳送；
第二次揮手：伺服器b收到這個fin，它發回乙個ack，確認序號為收到的序號加1，和syn一樣，乙個fin將占用乙個序號；
第三次揮手：伺服器b關閉與客戶端a的連線，傳送乙個fin給客戶端a；
第四次揮手：客戶端a發回ack報文確認，並將確認序號設定為收到序號加1；
客戶端主動關閉
client---------------------------------server
fin_wait_1 —fin m---------->close_wait(被動關閉)
fin_wait_2 <–ack m+1--------
time_wait <------fin n------ last_ack
----ack n+1 -------> closed
簡單的說就是
客戶端對伺服器說：我不愛你了，咱們離婚吧！--------------->（fin_wait_1狀態，等待回應）
伺服器說：那離婚吧，把你的東西都拿走！ --------------->（fin_wait_2狀態，在關閉連線前將最後一點資料傳完）
伺服器又說：咱們來個kiss goodbye吧！ --------------->（last_ack，關閉連線，並請求最後一次確認）
客戶端回應：波兒～ --------------> （closed，完畢）
以下問題來自網路
1．為什麼建立連線協議是三次握手，而關閉連線卻是四次握手呢？
這是因為服務端的listen狀態下的socket當收到syn報文的建連請求後，它可以把ack和syn（ack起應答作用，而syn起同步作用）放在乙個報文裡來傳送。但關閉連線時，當收到對方的fin報文通知時，它僅僅表示對方沒有資料傳送給你了；但未必你所有的資料都全部傳送給對方了，所以你未必會馬上會關閉socket,即你可能還需要傳送一些資料給對方之後，再傳送fin報文給對方來表示你同意現在可以關閉連線了，所以它這裡的ack報文和fin報文多數情況下都是分開傳送的。
2．為什麼time_wait狀態還需要等2msl後才能返回到closed狀態？
注:msl(最大分段生存期)指明tcp報文在internet上最長生存時間，每個具體的tcp實現都必須選擇乙個確定的msl值。rfc 1122建議是2分鐘，但bsd傳統實現採用了30秒。time_wait 狀態最大保持時間是2 * msl，也就是1-4分鐘。
time_wait的等待時間為2msl，即最大段生存時間.如果 time_wait 狀態保持時間不足夠長(比如小於2msl)，第乙個連線就正常終止了。第二個擁有相同相關五元組的連線出現(因為連線終止前發起的一方可能需要重發 ack，所以停留在該狀態的時間必須為msl的2倍。)，而第乙個連線的重複報文到達，干擾了第二個連線。tcp實現必須防止某個連線的重複報文在連線終止後出現，所以讓time_wait態保持時間足夠長(2msl)，連線相應方向上的tcp報文要麼完全響應完畢，要麼被丟棄。建立第二個連線的時候，不會混淆。
注:msl(最大分段生存期)指明tcp報文在internet上最長生存時間，每個具體的tcp實現都必須選擇乙個確定的msl值。rfc 1122建議是2分鐘，但bsd傳統實現採用了30秒。time_wait 狀態最大保持時間是2 * msl，也就是1-4分鐘。
這是因為雖然雙方都同意關閉連線了，而且握手的4個報文也都協調和傳送完畢，按理可以直接回到closed狀態（就好比從syn_send狀態到 establish狀態那樣）；但是因為我們必須要假想網路是不可靠的，你無法保證你最後傳送的ack報文會一定被對方收到，因此對方處於 last_ack狀態下的socket可能會因為超時未收到ack報文，而重發fin報文，所以這個time_wait狀態的作用就是用來重發可能丟失的 ack報文。
3.syn攻擊
例項：攻擊主機c(位址偽裝後為c』)-----大量syn包---->被攻擊主機
c』<-------syn/ack包----被攻擊主機
由於c』位址不可達，被攻擊主機等待syn包超時。攻擊主機通過發大量syn包填滿未連線佇列，導致正常syn包被拒絕服務。另外，syn洪水攻擊還可以通過發大量ack包進行dos攻擊。
from：
如何編寫socket套接字？（程式設計師面試寶典）
答案：伺服器端程式編寫：
（1） 呼叫serversocket（int port）建立乙個伺服器套接字，並繫結到指定埠上。
（2） 呼叫accept（），監聽連線請求，接收連線，返回通訊套接字。
（3） 呼叫socket類的getoutstream（）和getinputstream獲取輸出流和輸入流，開始網路資料的傳送和接收。
（4） 關閉通訊套接字socket.close( )。
客戶端程式編寫：
（1）呼叫socket（）建立乙個流套接字，並連線到伺服器端。
（2）呼叫socket類的getoutstream（）和getinputstream獲取輸出流和輸入流，開始網路資料的傳送和接收。
（3）關閉通訊套接字socket.close( )。
socket套接字程式編寫步驟
伺服器端程式的編寫步驟：
第一步：呼叫socket()函式建立乙個用於通訊的套接字。
第三步：呼叫listen()函式使套接字成為乙個監聽套接字。
第四步：呼叫accept()函式來接受客戶端的連線，這是就可以和客戶端通訊了。
第五步：處理客戶端的連線請求。
第六步：終止連線。
客戶端程式編寫步驟：、
第一步：呼叫socket()函式建立乙個用於通訊的套接字。
第三步：呼叫connect()函式來建立與伺服器的連線。
第四步：呼叫讀寫函式傳送或者接收資料。
第五步：終止連線。
TCP三次握手與四次分手
ack 此標誌表示應答域有效，就是說前面所說的tcp應答號將會包含在tcp資料報中 有兩個取值 0和1，為1的時候表示應答域有效，反之為0 syn 表示同步序號，用來建立連線。syn標誌位和ack標誌位搭配使用，當連線請求的時候，syn 1，ack 0 連線被響應的時候，syn 1，ack 1 這個...
TCP三次握手與四次分手
三次握手 解釋 客戶端a和伺服器b剛開始處於closed狀態，兩者之間沒有任何聯絡，a主動開啟，b被動開啟由 closed進入listen狀態，這是a傳送乙個syn 1的標誌位的資料報，並且資料的序列為seq x，a也由closed進入syn sent狀態，b接收到a的請求，也主動 傳送syn 1的...
tcp三次握手與四次分手
三次握手a主機請求b主機 a主機 先發 syn 1 seq a 給b主機 a主機進入syn sent狀態 b主機收到後傳送 syn 1 ack 1 seq b ack a 1 給a主機 b主機此時伺服器進入syn recv狀態 a主機收到後傳送ack 1 seq a 1 ack b 1 給b主機 客...