http 是應用層協(xié)議，主要解決如何包裝數(shù)據(jù)。

TCP/UDP是傳輸層協(xié)議，主要解決數(shù)據(jù)如何在網(wǎng)絡中傳輸。

Socket：是在應用層和傳輸層之間的一個抽象層，它把TCP/IP層復雜的操作抽象為幾個簡單的接口供應用層調(diào)用已實現(xiàn)進程在網(wǎng)絡中通信。

它是網(wǎng)絡通信過程中端點的抽象表示，包含進行網(wǎng)絡通信必須的五種信息：連接使用的協(xié)議，本地主機的IP地址，本地進程的協(xié)議端口，遠地主機的IP地址，遠地進程的協(xié)議端口。

應用層通過傳輸層進行數(shù)據(jù)通信時，TCP會遇到同時為多個應用程序進程提供并發(fā)服務的問題。多個TCP連接或多個應用程序進程可能需要通過同一個 TCP協(xié)議端口傳輸數(shù)據(jù)。為了區(qū)別不同的應用程序進程和連接，許多計算機操作系統(tǒng)為應用程序與TCP／IP協(xié)議交互提供了套接字(Socket)接口。應用層可以和傳輸層通過Socket接口，區(qū)分來自不同應用程序進程或網(wǎng)絡連接的通信，實現(xiàn)數(shù)據(jù)傳輸?shù)牟l(fā)服務。

套接字之間的連接過程分為三個步驟：服務器監(jiān)聽，客戶端請求，連接確認。

? ? ? ? ? ? ?服務器監(jiān)聽：服務器端套接字并不定位具體的客戶端套接字，而是處于等待連接的狀態(tài)，實時監(jiān)控網(wǎng)絡狀態(tài)，等待客戶端的連接請求。

? ? ? ? ? ? ?客戶端請求：指客戶端的套接字提出連接請求，要連接的目標是服務器端的套接字。為此，客戶端的套接字必須首先描述它要連接的服務器的套接字，指出服務器端套接字的地址和端口號，然后就向服務器端套接字提出連接請求。

? ? ? ? ? ? ?連接確認：當服務器端套接字監(jiān)聽到或者說接收到客戶端套接字的連接請求時，就響應客戶端套接字的請求，建立一個新的線程，把服務器端套接字的描述發(fā)給客戶端，一旦客戶端確認了此描述，雙方就正式建立連接。而服務器端套接字繼續(xù)處于監(jiān)聽狀態(tài)，繼續(xù)接收其他客戶端套接字的連接請求。

?TCP：面向連接、傳輸可靠(保證數(shù)據(jù)正確性,保證數(shù)據(jù)順序)、用于傳輸大量數(shù)據(jù)(流模式)、速度慢，建立連接需要開銷較多(時間，系統(tǒng)資源)。

UDP：面向非連接、傳輸不可靠、用于傳輸少量數(shù)據(jù)(數(shù)據(jù)包模式)、速度快。

開發(fā)時到底選擇TCP還是UDP? ? ? ? ?

?如果是由客戶端間歇性的發(fā)起無狀態(tài)的查詢，并且偶爾發(fā)生延遲是可以容忍，那么使用HTTP/HTTPS吧。 ? ? ? ?

?如果客戶端和服務器都可以獨立發(fā)包，但是偶爾發(fā)生延遲可以容忍（比如：在線的紙牌游戲，許多MMO類的游戲），那么使用TCP長連接吧。 ? ? ??

?如果客戶端和服務器都可以獨立發(fā)包，而且無法忍受延遲（比如：大多數(shù)的多人動作類游戲，一些MMO類游戲），那么使用UDP吧。

TCP三次握手建立連接

（關鍵字SYN(建立聯(lián)機 Synchronize Sequence Numbers確認鏈接序號) 、 ACK(確認 acknowledgement character 確認字符)）

? 第一次握手：客戶端發(fā)送一個TCP的SYN標志位置1的包指明客戶打算連接的服務器的端口，以及初始序號X,保存在包頭的序列號(Sequence Number)字段里。

?第二次握手：服務器發(fā)回確認包(ACK)應答。即SYN標志位和ACK標志位均為1同時，將確認序號(Acknowledgement Number)設置為客戶的序列號加1以，即X+1。

?第三次握手：客戶端再次發(fā)送確認包(ACK) SYN標志位為0，ACK標志位為1。并且把服務器發(fā)來ACK的序號字段+1，放在確定字段中發(fā)送給對方.并且在數(shù)據(jù)段放寫序列號的+1。

TCP四次揮手斷開連接

1、在整個通信的過程中，誰先發(fā)起請求，誰就是客戶端。

當客戶端的數(shù)據(jù)傳輸?shù)轿膊繒r，客戶端向服務器發(fā)送帶有FIN標志的數(shù)據(jù)包，使其明白自己準備斷開通信了。

2、因為TCP的通信是使用全雙工通信的WebSocket，所以在斷開連接的時候也應該是雙向的；當服務器收到帶有FIN標志的數(shù)據(jù)包時，其必不會直接發(fā)送FIN標志斷開通信的請求，而是先發(fā)送一個帶有ACK標志的應答信息，使客戶端明白服務器還有數(shù)據(jù)要進行發(fā)送。

3、當 服務器的數(shù)據(jù)發(fā)送完成后，向客戶端發(fā)送帶有FIN標志的數(shù)據(jù)包，通知客戶端斷開連接。

4、當客戶端收到FIN后，擔心網(wǎng)絡上某些不可控制的因素導致服務器不知道他要斷開連接，會發(fā)送ACK進行確認，同時把自己設置成TIME_WAIT狀態(tài)并啟動定時器，**在TCP的定時器到達后客戶端并沒有接收到請求，會重新發(fā)送；當服務器收到請求后就斷開連接；當客戶端等待2MLS（兩倍報文最大生存時間）后，沒有收到請求重傳的請求后，客戶端這邊就斷開連接，**整個TCP通信就結束了。

三次握手為什么不能改成兩次握手？

解：三次握手中的每一次都是必須的。如果是兩次握手，在第二次結束后，服務器并不能保證客戶端已經(jīng)收到了第二次的請求，如此一來的話，服務器會一直保存著這個通信過程，因為TCP通信都是要占用端口的，造成了一定的資源浪費。所以，就一定要讓客戶端來發(fā)送ACK的確認請求。

為什么不是4次？

因為3次之后就能保證客服端能收到服務器端的消息，服務器端能收到客服端的消息，4次造成時間和資源的浪費。

如果兩次，那么B無法確定B的信息A是否能收到，所以如果B先說話，可能后面的A都收不到，會出現(xiàn)問題 。如果四次，那么就造成了浪費，因為在三次結束之后，就已經(jīng)可以保證A可以給B發(fā)信息，A可以收到B的信息； B可以給A發(fā)信息，B可以收到A的信息。

關閉的時候為什么會是四次揮手？

解：四次揮手不能像三次握手一樣，三次握手可以將ACK+SYN 一起發(fā)送，ACK用于確認信息，SYN卻是用來建立聯(lián)機的；四次揮手中ACK是不能和FIN一起發(fā)送，ACK只是告訴客戶端確認我收到了，等我將數(shù)據(jù)發(fā)送完畢之后會向其發(fā)送FIN的標志，所以四次揮手是不能夠改變的。

http鏈接和socket鏈接的區(qū)別?

短連接：

? ?連接 -> 傳輸數(shù)據(jù)->關閉連接。就建立一次，但任務結束就中斷連接。?

?長連接：

? ? 連接 -> 傳輸數(shù)據(jù) -> 保持連接 -> 傳輸數(shù)據(jù)。。。-> 關閉連接。是指連接后不管是否使用都保持連接，但安全性較差。

Http連接：http連接就是所謂的短連接，即客戶端向服務器端發(fā)送一次請求，服務器端響應后連接即會斷掉；?socket連接：socket連接就是所謂的長連接，理論上客戶端和服務器端一旦建立起連接將不會主動斷掉；但是由于各種環(huán)境因素可能會是連接斷開，比如說：服務器端或客戶端主機down了，網(wǎng)絡故障，或者兩者之間長時間沒有數(shù)據(jù)傳輸，網(wǎng)絡防火墻可能會斷開該連接以釋放網(wǎng)絡資源。所以當一個socket連接中沒有數(shù)據(jù)的傳輸，那么為了維持連接需要發(fā)送心跳消息~~具體心跳消息格式是開發(fā)者自己定義的.