TCP連接的三次握手：
第一步，服務端處於開啟狀態，一直阻塞着，監聽某一個端口。
第二步，客戶端啟動，給服務端發送請求建立連接，服務端收到這個請求之后，解析之后就立刻回復一個請求給客戶端，如果客戶端在發送請求之后長時間沒有收到服務端發來的回復，會重新發送這個請求，之前的那個請求就會作廢，客戶端在收到服務端發送過來的數據，會再發送一次響應給服務端，也就是，客戶端先發送一個請求，看看服務端有沒有響應發回來，服務端發送一個請求，看看客戶端有沒有響應回來，但是服務端的響應和請求可以合並為一次發送，所以就是客戶端發一次，服務端響應一次，客戶端再響應一次，然后連接就算建立成功，開始傳輸數據。
斷開連接四次揮手：
首先是客戶端在數據發送完之后，發送一個斷開請求給服務端，告訴服務端，我數據發完了，我這邊可以斷開了，服務端收到這個消息之后，回復一個，我收到了，但是這個時候服務端的數據可能還沒有發送完，服務端還得繼續發送，到服務端發送完之后，再發送一個消息給客戶端，告訴客戶端，我數據也發送完了，客戶端收到這個消息之后，回復一個消息給服務端，說，我收到了，那我們可以斷開了，然后客戶端這邊就開始斷開連接了。 服務端收到這個消息之后，也就斷開連接。
為什么斷開鏈接比建立連接多一次，因為建立連接的時候，服務端的回復響應和發送請求，兩次合並成為了一次，中間沒有時間間隔，但是在斷開連接的時候，可能客戶端數據發送完了之后，服務端這邊可能還沒有發送完，所以，這里的兩次發送不能合並成一次，所以有四次。
上圖中有幾個字段需要重點介紹下：
（1）序號：Seq序號，占32位，用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記。
（2）確認序號：Ack序號，占32位，只有ACK標志位為1時，確認序號字段才有效，Ack=Seq+1。
確認方Ack=發起方Req+1，兩端配對
1.1 3次握手過程詳解
所謂三次握手（Three-Way Handshake）即建立TCP連接，就是指建立一個TCP連接時，需要客戶端和服務端總共發送3個包以確認連接的建立。在socket編程中，這一過程由客戶端執行connect來觸發，整個流程如下圖所示：
（1）第一次握手：
Client將標志位SYN置為1，隨機產生一個值seq=J，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。
（2）第二次握手：
Server收到數據包后由標志位SYN=1知道Client請求建立連接，Server將標志位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認連接請求，Server進入SYN_RCVD狀態。
（3）第三次握手：
Client收到確認后，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨后Client與Server之間可以開始傳輸數據了。
SYN攻擊：
在三次握手過程中，Server發送SYN-ACK之后，收到Client的ACK之前的TCP連接稱為半連接（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK后，Server轉入ESTABLISHED狀態。SYN攻擊就是Client在短時間內偽造大量不存在的IP地址，並向Server不斷地發送SYN包，Server回復確認包，並等待Client的確認，由於源地址是不存在的，因此，Server需要不斷重發直至超時，這些偽造的SYN包將產時間占用未連接隊列，導致正常的SYN請求因為隊列滿而被丟棄，從而引起網絡堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單，即當Server上有大量半連接狀態且源IP地址是隨機的，則可以斷定遭到SYN攻擊了，使用如下命令可以讓之現行：
#netstat -nap | grep SYN_RECV
1.2 4次揮手過程詳解
由於TCP連接時全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成數據發送任務后，發送一個FIN來終止這一方向的連接，收到一個FIN只是意味着這一方向上沒有數據流動了，即不會再收到數據了，但是在這個TCP連接上仍然能夠發送數據，直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉，而另一方則執行被動關閉，上圖描述的即是如此。
第一次揮手：
Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。
第二次揮手：
Server收到FIN后，發送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號），Server進入CLOSE_WAIT狀態。
第三次揮手：
Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。
第四次揮手：
Client收到FIN后，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。
上面是一方主動關閉，另一方被動關閉的情況，實際中還會出現同時發起主動關閉的情況，具體流程如下圖：
結語
關於三次握手與四次揮手通常都會有典型的面試題，在此提出供有需求的XDJM們參考：
(1) 三次握手是什么或者流程？四次握手呢？答案前面分析就是。
(2) 為什么建立連接是三次握手，而關閉連接卻是四次揮手呢？
這是因為服務端在LISTEN狀態下，收到建立連接請求的SYN報文后，把ACK和SYN放在一個報文里發送給客戶端。而關閉連接時，當收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還能接收數據，己方也未必全部數據都發送給對方了，所以己方可以立即close，也可以發送一些數據給對方后，再發送FIN報文給對方來表示同意現在關閉連接，因此，己方ACK和FIN一般都會分開發送。
2. tcp 與udp 比較
TCP的優點：
可靠，穩定 TCP的可靠體現在TCP在傳遞數據之前，會有三次握手來建立連接，而且在數據傳遞時，有確認、窗口、重傳、擁塞控制機制，在數據傳完后，還會斷開連接用來節約系統資源。
TCP的缺點：
慢，效率低，占用系統資源高，易被攻擊 TCP在傳遞數據之前，要先建連接，這會消耗時間，而且在數據傳遞時，確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間，而且要在每台設備上維護所有的傳輸連接，事實上，每個連接都會占用系統的CPU、內存等硬件資源。 而且，因為TCP有確認機制、三次握手機制，這些也導致TCP容易被人利用，實現DOS、DDOS、CC等攻擊。
UDP的優點：
快，比TCP稍安全 UDP沒有TCP的握手、確認、窗口、重傳、擁塞控制等機制，UDP是一個無狀態的傳輸協議，所以它在傳遞數據時非常快。沒有TCP的這些機制，UDP較TCP被攻擊者利用的漏洞就要少一些。但UDP也是無法避免攻擊的，比如：UDP Flood攻擊……
UDP的缺點：
不可靠，不穩定 因為UDP沒有TCP那些可靠的機制，在數據傳遞時，如果網絡質量不好，就會很容易丟包。
基於上面的優缺點，那么：
什么時候應該使用TCP： 當對網絡通訊質量有要求的時候，比如：整個數據要准確無誤的傳遞給對方，這往往用於一些要求可靠的應用，比如HTTP、HTTPS、FTP等傳輸文件的協議，POP、SMTP等郵件傳輸的協議。 在日常生活中，常見使用TCP協議的應用如下： 瀏覽器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件傳輸 …………
什么時候應該使用UDP： 當對網絡通訊質量要求不高的時候，要求網絡通訊速度能盡量的快，這時就可以使用UDP。 比如，日常生活中，常見使用UDP協議的應用如下： QQ語音 QQ視頻 TFTP ……
有些應用場景對可靠性要求不高會用到UPD，比如長視頻，要求速率
UDP應用場景：
1.面向數據報方式 2.網絡數據大多為短消息 3.擁有大量Client 4.對數據安全性無特殊要求 5.網絡負擔非常重，但對響應速度要求高具體編程時的區別 1.socket()的參數不同 2.UDP Server不需要調用listen和accept 3.UDP收發數據用sendto/recvfrom函數 4.TCP：地址信息在connect/accept時確定 5.UDP：在sendto/recvfrom函數中每次均 需指定地址信息 6.UDP：shutdown函數無效編程區別 通常我們在說到網絡編程時默認是指TCP編程，即用前面提到的socket函數創建一個socket用於TCP通訊，函數參數我們通常填為SOCK_STREAM。即socket(PF_INET, SOCK_STREAM, 0)，這表示建立一個socket用於流式網絡通訊。 SOCK_STREAM這種的特點是面向連接的，即每次收發數據之前必須通過connect建立連接，也是雙向的，即任何一方都可以收發數據，協議本身提供了一些保障機制保證它是可靠的、有序的，即每個包按照發送的順序到達接收方。 而SOCK_DGRAM這種是User Datagram Protocol協議的網絡通訊，它是無連接的，不可靠的，因為通訊雙方發送數據后不知道對方是否已經收到數據，是否正常收到數據。任何一方建立一個socket以后就可以用sendto發送數據，也可以用recvfrom接收數據。根本不關心對方是否存在，是否發送了數據。它的特點是通訊速度比較快。大家都知道TCP是要經過三次握手的，而UDP沒有。
TCP和UDP是OSI模型中的運輸層中的協議。TCP提供可靠的通信傳輸，而UDP則常被用於讓廣播和細節控制交給應用的通信傳輸。
UDP補充：
UDP不提供復雜的控制機制，利用IP提供面向無連接的通信服務。並且它是將應用程序發來的數據在收到的那一刻，立刻按照原樣發送到網絡上的一種機制。即使是出現網絡擁堵的情況下，UDP也無法進行流量控制等避免網絡擁塞的行為。此外，傳輸途中如果出現了丟包，UDP也不負責重發。甚至當出現包的到達順序亂掉時也沒有糾正的功能。如果需要這些細節控制，那么不得不交給由采用UDP的應用程序去處理。換句話說，UDP將部分控制轉移到應用程序去處理，自己卻只提供作為傳輸層協議的最基本功能。UDP有點類似於用戶說什么聽什么的機制，但是需要用戶充分考慮好上層協議類型並制作相應的應用程序。
TCP補充：
TCP充分實現了數據傳輸時各種控制功能，可以進行丟包的重發控制，還可以對次序亂掉的分包進行順序控制。而這些在UDP中都沒有。此外，TCP作為一種面向有連接的協議，只有在確認通信對端存在時才會發送數據，從而可以控制通信流量的浪費。TCP通過檢驗和、序列號、確認應答、重發控制、連接管理以及窗口控制等機制實現可靠性傳輸。
小結TCP與UDP的區別：
1、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發送數據之前不需要建立連接
2、TCP提供可靠的服務。也就是說，通過TCP連接傳送的數據，無差錯，不丟失，不重復，且按序到達;UDP盡最大努力交付，即不保證可靠交付
3、TCP面向字節流，實際上是TCP把數據看成一連串無結構的字節流;UDP是面向報文的
UDP沒有擁塞控制，因此網絡出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如IP電話，實時視頻會議等）
4、每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信
5、TCP首部開銷20字節;UDP的首部開銷小，只有8個字節 。 對系統資源的要求（TCP較多，UDP少）；
6、TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道