TCP協議的三次握手和四次揮手：
注：seq:"sequance"序列號；ack:"acknowledge"確認號；SYN:"synchronize"請求同步標誌；；ACK:"acknowledge"確認標誌"；FIN："Finally"結束標誌。
TCP連接建立過程：首先Client端發送連接請求報文，Server段接受連接後回覆ACK報文，併爲這次連接分配資源。Client端接收到ACK報文後也向Server段發生ACK報文，並分配資
一個完整的TCP流，包括三次握手，請求傳輸內容，確認接受無誤，http協議傳輸內容和四次揮手。
三次握手源，這樣TCP連接就建立了。
第一次握手：客戶端發送一個TCP，標誌位爲SYN，序列號爲0， 代表客戶端請求建立連接。
第二次握手：服務器發回確認包, 標誌位爲SYN,ACK. 將確認序號(Acknowledgement Number)設置爲客戶的I S N加1以.即0+1=1。
第三次握手：客戶端再次發送確認包(ACK) SYN標誌位爲0,ACK標誌位爲1.並且把服務器發來ACK的序號字段+1,放在確定字段中發送給對方.並且在數據段放寫ISN的+1
TCP連接斷開過程：假設Client端發起中斷連接請求，也就是發送FIN報文。Server端接到FIN報文後，意思是說"我Client端沒有數據要發給你了"，但是如果你還有數據沒有發送完成，則不必急着關閉Socket，可以繼續發送數據。所以你先發送ACK，"告訴Client端，你的請求我收到了，但是我還沒準備好，請繼續你等我的消息"。這個時候Client端就進入FIN_WAIT狀態，繼續等待Server端的FIN報文。當Server端確定數據已發送完成，則向Client端發送FIN報文，"告訴Client端，好了，我這邊數據發完了，準備好關閉連接了"。Client端收到FIN報文後，"就知道可以關閉連接了，但是他還是不相信網絡，怕Server端不知道要關閉，所以發送ACK後進入TIME_WAIT狀態，如果Server端沒有收到ACK則可以重傳。“Server端收到ACK後，"就知道可以斷開連接了"。Client端等待了2MSL後依然沒有收到回覆，則證明Server端已正常關閉，那好，我Client端也可以關閉連接了。Ok，TCP連接就這樣關閉了！
爲什麼要三次握手？
在只有兩次“握手”的情形下，假設Client想跟Server建立連接，但是卻因爲中途連接請求的數據報丟失了，故Client端不得不重新發送一遍；這個時候Server端僅收到一個連接請求，因此可以正常的建立連接。但是，有時候Client端重新發送請求不是因爲數據報丟失了，而是有可能數據傳輸過程因爲網絡併發量很大在某結點被阻塞了，這種情形下Server端將先後收到2次請求，並持續等待兩個Client請求向他發送數據...問題就在這裏，Cient端實際上只有一次請求，而Server端卻有2個響應，極端的情況可能由於Client端多次重新發送請求數據而導致Server端最後建立了N多個響應在等待，因而造成極大的資源浪費！所以，“三次握手”很有必要！
爲什麼要四次揮手？
試想一下，假如現在你是客戶端你想斷開跟Server的所有連接該怎麼做？第一步，你自己先停止向Server端發送數據，並等待Server的回覆。但事情還沒有完，雖然你自身不往Server發送數據了，但是因爲你們之前已經建立好平等的連接了，所以此時他也有主動權向你發送數據；故Server端還得終止主動向你發送數據，並等待你的確認。其實，說白了就是保證雙方的一個合約的完整執行！
使用TCP的協議：FTP（文件傳輸協議）、Telnet（遠程登錄協議）、SMTP（簡單郵件傳輸協議）、POP3（和SMTP相對，用於接收郵件）、HTTP協議等。
