網(wǎng)絡(luò)如何通信

我們要理解網(wǎng)絡(luò)中進程如何通信敬辣，得解決兩個問題：
　∨２浮ａ达传、我們要如何標識一臺主機篙耗，即怎樣確定我們將要通信的進程是在那一臺主機上運行。
　∠芨稀ｂ宗弯、我們要如何標識唯一進程，本地通過pid標識搂妻，網(wǎng)絡(luò)中應(yīng)該怎樣標識蒙保？
解決辦法：
　　ａ叽讳、TCP/IP協(xié)議族已經(jīng)幫我們解決了這個問題追他，網(wǎng)絡(luò)層的“ip地址”可以唯一標識網(wǎng)絡(luò)中的主機
　　ｂ岛蚤、傳輸層的“協(xié)議+端口”可以唯一標識主機中的應(yīng)用程序（進程）邑狸，因此，我們利用三元組（ip地址涤妒，協(xié)議单雾，端口）就可以標識網(wǎng)絡(luò)的進程了，網(wǎng)絡(luò)中的進程通信就可以利用這個標志與其它進程進行交互

以UDP傳輸為例：

1156719-d9684a2e160f62ad.png

網(wǎng)絡(luò)的七層模型

v2-1dd6e1ed2f348db47ce0cde38d545ae9_1440w.jpg

11362584-d6275ac25abac5cc.jpeg

1她紫、物理層：
解決兩個硬件之間怎么通信的問題硅堆，常見的物理媒介有光纖、電纜贿讹、中繼器等渐逃。它主要定義物理設(shè)備標準，如網(wǎng)線的接口類型民褂、光纖的接口類型茄菊、各種傳輸介質(zhì)的傳輸速率等。

它的主要作用是傳輸比特流（就是由1赊堪、0轉(zhuǎn)化為電流強弱來進行傳輸面殖，到達目的地后在轉(zhuǎn)化為1、0哭廉，也就是我們常說的數(shù)模轉(zhuǎn)換與模數(shù)轉(zhuǎn)換）脊僚。這一層的數(shù)據(jù)叫做比特。

2遵绰、數(shù)據(jù)鏈路層：
在計算機網(wǎng)絡(luò)中由于各種干擾的存在辽幌，物理鏈路是不可靠的增淹。該層的主要功能就是：通過各種控制協(xié)議，將有差錯的物理信道變?yōu)闊o差錯的舶衬、能可靠傳輸數(shù)據(jù)幀的數(shù)據(jù)鏈路埠通。

它的具體工作是接收來自物理層的位流形式的數(shù)據(jù)，并封裝成幀逛犹，傳送到上一層端辱；同樣，也將來自上層的數(shù)據(jù)幀虽画，拆裝為位流形式的數(shù)據(jù)轉(zhuǎn)發(fā)到物理層舞蔽。這一層的數(shù)據(jù)叫做幀。

3码撰、網(wǎng)絡(luò)層：
計算機網(wǎng)絡(luò)中如果有多臺計算機渗柿，怎么找到要發(fā)的那臺？如果中間有多個節(jié)點脖岛，怎么選擇路徑朵栖？這就是路由要做的事。

該層的主要任務(wù)就是：通過路由選擇算法柴梆，為報文（該層的數(shù)據(jù)單位陨溅，由上一層數(shù)據(jù)打包而來）通過通信子網(wǎng)選擇最適當?shù)穆窂健＿@一層定義的是IP地址绍在，通過IP地址尋址门扇，所以產(chǎn)生了IP協(xié)議。

4偿渡、傳輸層：
當發(fā)送大量數(shù)據(jù)時臼寄，很可能會出現(xiàn)丟包的情況，另一臺電腦要告訴是否完整接收到全部的包溜宽。如果缺了吉拳，就告訴丟了哪些包，然后再發(fā)一次适揉，直至全部接收為止留攒。

簡單來說，傳輸層的主要功能就是：監(jiān)控數(shù)據(jù)傳輸服務(wù)的質(zhì)量涡扼，保證報文的正確傳輸。

5盟庞、會話層：
雖然已經(jīng)可以實現(xiàn)給正確的計算機吃沪，發(fā)送正確的封裝過后的信息了。但我們總不可能每次都要調(diào)用傳輸層協(xié)議去打包什猖，然后再調(diào)用IP協(xié)議去找路由票彪，所以我們要建立一個自動收發(fā)包红淡，自動尋址的功能。于是會話層出現(xiàn)了：它的作用就是建立和管理應(yīng)用程序之間的通信降铸。

6在旱、表示層：
表示層負責數(shù)據(jù)格式的轉(zhuǎn)換，將應(yīng)用處理的信息轉(zhuǎn)換為適合網(wǎng)絡(luò)傳輸?shù)母袷酵频В蛘邔碜韵乱粚拥臄?shù)據(jù)轉(zhuǎn)換為上層能處理的格式桶蝎。

7、應(yīng)用層：
應(yīng)用層是計算機用戶谅畅，以及各種應(yīng)用程序和網(wǎng)絡(luò)之間的接口登渣，其功能是直接向用戶提供服務(wù)，完成用戶希望在網(wǎng)絡(luò)上完成的各種工作毡泻。前端同學對應(yīng)用層肯定是最熟悉的胜茧。

TCP/IP協(xié)議、UDP仇味、HTTP協(xié)議呻顽、SOCKET通訊

應(yīng)用層（應(yīng)用，表示丹墨，會話）：TFTP廊遍，HTTP，SNMP带到，F(xiàn)TP昧碉，SMTP，DNS揽惹，Telnet 等等
傳輸層：TCP被饿，UDP
網(wǎng)絡(luò)層：IP，ICMP搪搏，OSPF狭握，EIGRP，IGMP
數(shù)據(jù)鏈路層：SLIP疯溺，CSLIP论颅，PPP，MTU
重要的 協(xié)議族介紹:

• IP(Internet Protocol,網(wǎng)際協(xié)議)是網(wǎng)間層的主要協(xié)議,任務(wù)是在源地址和和目的地址之間傳輸數(shù)據(jù)囱嫩。IP 協(xié)議只是盡最大努力來傳輸數(shù)據(jù)包,并不保證所有的包都可以傳輸 到目的地,也不保證數(shù)據(jù)包的順序和唯一恃疯。

IP 定義了 TCP/IP 的地址,尋址方法,以及路由規(guī)則。現(xiàn)在廣泛使用的 IP 協(xié)議有 IPv4 和 IPv6 兩種:IPv4 使用 32 位二進制整數(shù)做地址,一般使用點分十進制方式表示,比如 192.168.0.1墨闲。
IP 地址由兩部分組成,即網(wǎng)絡(luò)號和主機號今妄。故一個完整的 IPv4 地址往往表示 為 192.168.0.1/24 或192.168.0.1/255.255.255.0 這種形式。
IPv6 是為了解決 IPv4 地址耗盡和其它一些問題而研發(fā)的最新版本的 IP。使用 128 位 整數(shù)表示地址,通常使用冒號分隔的十六進制來表示,并且可以省略其中一串連續(xù)的 0,如:fe80::200:1ff:fe00:1盾鳞。
目前使用并不多犬性！

• ICMP(Internet Control Message Protocol,網(wǎng)絡(luò)控制消息協(xié)議)是 TCP/IP 的 核心協(xié)議之一,用于在 IP 網(wǎng)絡(luò)中發(fā)送控制消息,提供通信過程中的各種問題反饋。 ICMP 直接使用 IP 數(shù)據(jù)包傳輸,但 ICMP 并不被視為 IP 協(xié)議的子協(xié)議腾仅。常見的聯(lián)網(wǎng)狀態(tài)診斷工具比如依賴于 ICMP 協(xié)議;

• UDP乒裆，在傳送數(shù)據(jù)前不需要先建立連接，遠地的主機在收到UDP報文后也不需要給出任何確認推励。雖然UDP不提供可靠交付鹤耍，但是正是因為這樣，省去和很多的開銷吹艇，使得它的速度比較快惰蜜，比如一些對實時性要求較高的服務(wù)，就常常使用的是UDP受神。對應(yīng)的應(yīng)用層的協(xié)議主要有 DNS,TFTP,DHCP,SNMP,NFS 等抛猖。

• TCP/IP，TCP/IP【TCP（傳輸控制協(xié)議）和IP（網(wǎng)際協(xié)議）】提供點對點的鏈接機制鼻听，將數(shù)據(jù)應(yīng)該如何封裝财著、定址、傳輸撑碴、路由以及在目的地如何接收撑教，都加以標準化。在傳送數(shù)據(jù)之前必須先建立連接醉拓，數(shù)據(jù)傳送完成后要釋放連接伟姐。因此TCP是一種可靠的的運輸服務(wù)，但是正因為這樣亿卤，不可避免的增加了許多的開銷愤兵，比如確認，流量控制等排吴。對應(yīng)的應(yīng)用層的協(xié)議主要有 SMTP,TELNET,HTTP,FTP 等秆乳。

• ECHO(EchoProtocol,回聲協(xié)議)是一個簡單的調(diào)試和檢測工具。服務(wù)器器會 原樣回發(fā)它收到的任何數(shù)據(jù),既可以使用 TCP 傳輸,也可以使用 UDP 傳輸钻哩。使用 端口號 7 屹堰。

• DHCP(DynamicHostConfigrationProtocol,動態(tài)主機配置協(xié)議)是用于局域 網(wǎng)自動分配 IP 地址和主機配置的協(xié)議〗智猓可以使局域網(wǎng)的部署更加簡單扯键。

• DNS(DomainNameSystem,域名系統(tǒng))是互聯(lián)網(wǎng)的一項服務(wù),可以簡單的將用“.” 分隔的一般會有意義的域名轉(zhuǎn)換成不易記憶的 IP 地址。一般使用 UDP 協(xié)議傳輸, 也可以使用 TCP,默認服務(wù)端口號 53珊肃。

• FTP(FileTransferProtocol,文件傳輸協(xié)議)是用來進行文件傳輸?shù)臉藴蕝f(xié)議荣刑。 FTP 基于 TCP 使用端口號 20 來傳輸數(shù)據(jù),21 來傳輸控制信息扣泊。

• TFTP(Trivial File Transfer Protocol,簡單文件傳輸協(xié)議)是一個簡化的文 件傳輸協(xié)議,其設(shè)計非常簡單,通過少量存儲器就能輕松實現(xiàn),所以一般被用來通 過網(wǎng)絡(luò)引導(dǎo)計算機過程中傳輸引導(dǎo)文件等小文件;

• SSH(SecureShell,安全Shell),因為傳統(tǒng)的網(wǎng)絡(luò)服務(wù)程序比如TELNET本質(zhì)上都極不安全,明文傳說數(shù)據(jù)和用戶信息包括密碼,SSH 被開發(fā)出來避免這些問題, 它其實是一個協(xié)議框架,有大量的擴展冗余能力,并且提供了加密壓縮的通道可以 為其他協(xié)議使用。

• POP(PostOfficeProtocol,郵局協(xié)議)是支持通過客戶端訪問電子郵件的服務(wù), 現(xiàn)在版本是 POP3,也有加密的版本 POP3S嘶摊。協(xié)議使用 TCP,端口 110。

• SMTP(Simple Mail Transfer Protocol,簡單郵件傳輸協(xié)議)是現(xiàn)在在互聯(lián)網(wǎng) 上發(fā)送電子郵件的事實標準评矩。使用 TCP 協(xié)議傳輸,端口號 25叶堆。

• HTTP(HyperTextTransferProtocol,超文本傳輸協(xié)議)是現(xiàn)在廣為流行的WEB 網(wǎng)絡(luò)的基礎(chǔ),HTTPS 是 HTTP 的加密安全版本。協(xié)議通過 TCP 傳輸,HTTP 默認 使用端口 80,HTTPS 使用 443斥杜。

TCP/IP虱颗、UDP、HTTP的關(guān)系解釋

http協(xié)議對應(yīng)于應(yīng)用層蔗喂，tcp協(xié)議對應(yīng)于傳輸層忘渔，ip協(xié)議對應(yīng)于網(wǎng)絡(luò)層。
TPC/IP【TCP（傳輸控制協(xié)議）和IP（網(wǎng)際協(xié)議）】缰儿，主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸畦粮，而HTTP是應(yīng)用層協(xié)議，主要解決如何包裝數(shù)據(jù)乖阵。關(guān)于TCP/IP和HTTP協(xié)議的關(guān)系宣赔，網(wǎng)絡(luò)有一段比較容易理解的介紹：“我們在傳輸數(shù)據(jù)時，可以只使用（傳輸層）TCP/IP協(xié)議瞪浸，但是那樣的話儒将，如果沒有應(yīng)用層，便無法識別數(shù)據(jù)內(nèi)容对蒲，如果想要使傳輸?shù)臄?shù)據(jù)有意義钩蚊，則必須使用到應(yīng)用層協(xié)議，應(yīng)用層協(xié)議有很多蹈矮，比如HTTP砰逻、FTP、TELNET等含滴，也可以自己定義應(yīng)用層協(xié)議诱渤。WEB使用HTTP協(xié)議作應(yīng)用層協(xié)議，以封裝HTTP 文本信息谈况，然后使用TCP/IP做傳輸層協(xié)議將它發(fā)到網(wǎng)絡(luò)上勺美。”
　　術(shù)語TCP/IP代表傳輸控制協(xié)議/網(wǎng)際協(xié)議碑韵，指的是一系列協(xié)議赡茸。“IP”代表網(wǎng)際協(xié)議祝闻，TCP和UDP使用該協(xié)議從一個網(wǎng)絡(luò)傳送數(shù)據(jù)包到另一個網(wǎng)絡(luò)占卧。把IP想像成一種高速公路遗菠，它允許其它協(xié)議在上面行駛并找到到其它電腦的出口。TCP和UDP是高速公路上的“卡車”华蜒，它們攜帶的貨物就是像HTTP辙纬，文件傳輸協(xié)議FTP這樣的協(xié)議等。
你應(yīng)該能理解叭喜，TCP和UDP是FTP贺拣，HTTP和SMTP之類使用的傳輸層協(xié)議。雖然TCP和UDP都是用來傳輸其他協(xié)議的捂蕴，它們卻有一個顯著的不同：TCP提供有保證的數(shù)據(jù)傳輸譬涡，而UDP不提供。這意味著TCP有一個特殊的機制來確保數(shù)據(jù)安全的不出錯的從一個端點傳到另一個端點啥辨，而UDP不提供任何這樣的保證涡匀。

URL

URL的全稱是Uniform Resource Locator（統(tǒng)一資源定位符）
通過1個URL，能找到互聯(lián)網(wǎng)上唯一的1個資源溉知。
URL就是資源的地址陨瘩、位置，互聯(lián)網(wǎng)上的每個資源都有一個唯一的URL级乍。

URL的基本格式 =協(xié)議://主機地址/路徑
協(xié)議：不同的協(xié)議拾酝，代表著不同的資源查找方式、資源傳輸方式
主機地址：存放資源的主機（服務(wù)器）的IP地址（域名）
資源在主機（服務(wù)器）中的具體位置

http

• HTTP超文本傳輸協(xié)議：是短連接卡者，是客戶端主動發(fā)送請求蒿囤，服務(wù)器作出響應(yīng)，響應(yīng)之后服務(wù)器斷開崇决。HTTP屬于應(yīng)用層面向?qū)ο髤f(xié)議材诽，HTTP有兩類報文：請求報文和相應(yīng)報文。
  請求報文包含：請求行恒傻、請求頭脸侥、空行、請求數(shù)據(jù)四部分組成盈厘。
  響應(yīng)報文包含：狀態(tài)行睁枕、消息報文、響應(yīng)正文三部分組成沸手。
  通常外遇，HTTP請求方式使用POST和GET發(fā)送數(shù)據(jù)發(fā)送。
  1契吉、POST：它將發(fā)送的數(shù)據(jù)單獨放在一個流中進行發(fā)送跳仿，而不是附加到URL地址后面，這樣做的好處是這些數(shù)據(jù)不會出現(xiàn)在URL地址中捐晶。
  2菲语、GET：它將發(fā)送的數(shù)據(jù)直接添加到URL后面妄辩，用&鏈接，這樣的好處是不用另外的數(shù)據(jù)流來發(fā)送這些數(shù)據(jù)山上，但是缺點是將用戶信息暴露出來了眼耀，不安全。

1佩憾、HTTP協(xié)議的幾個重要概念
1.連接(Connection)：一個傳輸層的實際環(huán)流畔塔，它是建立在兩個相互通訊的應(yīng)用程序之間。
2.消息(Message)：HTTP通訊的基本單位鸯屿，包括一個結(jié)構(gòu)化的八元組序列并通過連接傳輸。
3.請求(Request)：一個從客戶端到服務(wù)器的請求信息包括應(yīng)用于資源的方法把敢、資源的標識符和協(xié)議的版本號
4.響應(yīng)(Response)：一個從服務(wù)器返回的信息包括HTTP協(xié)議的版本號寄摆、請求的狀態(tài)(例如“成功”或“沒找到”)和文檔的MIME類型。
5.資源(Resource)：由URI標識的網(wǎng)絡(luò)數(shù)據(jù)對象或服務(wù)修赞。
6.實體(Entity)：數(shù)據(jù)資源或來自服務(wù)資源的回映的一種特殊表示方法婶恼，它可能被包圍在一個請求或響應(yīng)信息中。一個實體包括實體頭信息和實體的本身內(nèi)容柏副。
7.客戶機(Client)：一個為發(fā)送請求目的而建立連接的應(yīng)用程序勾邦。
8.用戶代理(Useragent)：初始化一個請求的客戶機。它們是瀏覽器割择、編輯器或其它用戶工具眷篇。
9.服務(wù)器(Server)：一個接受連接并對請求返回信息的應(yīng)用程序。
10.源服務(wù)器(Originserver)：是一個給定資源可以在其上駐留或被創(chuàng)建的服務(wù)器荔泳。
11.代理(Proxy)：一個中間程序蕉饼，它可以充當一個服務(wù)器，也可以充當一個客戶機玛歌，為其它客戶機建立請求昧港。請求是通過可能的翻譯在內(nèi)部或經(jīng)過傳遞到其它的服務(wù)器中。一個代理在發(fā)送請求信息之前支子，必須解釋并且如果可能重寫它创肥。
代理經(jīng)常作為通過防火墻的客戶機端的門戶，代理還可以作為一個幫助應(yīng)用來通過協(xié)議處理沒有被用戶代理完成的請求值朋。
12.網(wǎng)關(guān)(Gateway)：一個作為其它服務(wù)器中間媒介的服務(wù)器叹侄。與代理不同的是，網(wǎng)關(guān)接受請求就好象對被請求的資源來說它就是源服務(wù)器昨登；發(fā)出請求的客戶機并沒有意識到它在同網(wǎng)關(guān)打交道圈膏。
網(wǎng)關(guān)經(jīng)常作為通過防火墻的服務(wù)器端的門戶，網(wǎng)關(guān)還可以作為一個協(xié)議翻譯器以便存取那些存儲在非HTTP系統(tǒng)中的資源篙骡。
13.通道(Tunnel)：是作為兩個連接中繼的中介程序稽坤。一旦激活丈甸，通道便被認為不屬于HTTP通訊，盡管通道可能是被一個HTTP請求初始化的尿褪。當被中繼的連接兩端關(guān)閉時睦擂，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經(jīng)常使用杖玲。
14.緩存(Cache)：反應(yīng)信息的局域存儲顿仇。

socket

• socket 被翻譯為“套接字”，它是計算機之間進行通信的一種約定或一種方式摆马。通過 socket 這種約定臼闻，一臺計算機可以接收其他計算機的數(shù)據(jù)，也可以向其他計算機發(fā)送數(shù)據(jù)囤采。socket應(yīng)運而生述呐，它就是利用三元組解決網(wǎng)絡(luò)通信的一個中間件工具。
  Socket通信的數(shù)據(jù)傳輸方式蕉毯，常用的有兩種：
  　∨野帷ａ、SOCK_STREAM：表示面向連接的數(shù)據(jù)傳輸方式代虾。數(shù)據(jù)可以準確無誤地到達另一臺計算機进肯，如果損壞或丟失，可以重新發(fā)送棉磨，但效率相對較慢江掩。常見的 http 協(xié)議就使用 SOCK_STREAM 傳輸數(shù)據(jù)，因為要確保數(shù)據(jù)的正確性乘瓤，否則網(wǎng)頁不能正常解析频敛。
  　　ｂ馅扣、SOCK_DGRAM：表示無連接的數(shù)據(jù)傳輸方式斟赚。計算機只管傳輸數(shù)據(jù)，不作數(shù)據(jù)校驗差油，如果數(shù)據(jù)在傳輸中損壞拗军，或者沒有到達另一臺計算機，是沒有辦法補救的蓄喇。也就是說发侵，數(shù)據(jù)錯了就錯了，無法重傳妆偏。因為 SOCK_DGRAM 所做的校驗工作少刃鳄，所以效率比 SOCK_STREAM 高。
  　　c钱骂、第三方的開源庫CocoaAsyncSocket

TCP連接的三次握手四次揮手

TCP(Transmission Control Protocol) 傳輸控制協(xié)議叔锐。TCP是主機對主機層的傳輸控制協(xié)議挪鹏，提供可靠的連接服務(wù)，采用三次握確認建立一個連接愉烙。位碼即tcp標志位讨盒，有6種 標示:SYN(synchronous建立聯(lián)機) ACK(acknowledgement 確認) PSH(push傳送) FIN(finish結(jié)束) RST(reset重置) URG(urgent緊急)Sequence number(順序號碼) Acknowledge number(確認號碼)。

手機能夠使用聯(lián)網(wǎng)功能是因為手機底層實現(xiàn)了TCP/IP協(xié)議步责，可以使手機終端通過無線網(wǎng)絡(luò)建立TCP連接返顺。TCP協(xié)議可以對上層網(wǎng)絡(luò)提供接口，使上層網(wǎng)絡(luò)數(shù)據(jù)的傳輸建立在“無差別”的網(wǎng)絡(luò)之上蔓肯。建立起一個TCP連接需要經(jīng)過“三次握手”：

第一次握手：客戶端發(fā)送syn包(syn=j)到服務(wù)器遂鹊，并進入SYN_SEND狀態(tài)，等待服務(wù)器確認蔗包；

第二次握手：服務(wù)器收到syn包秉扑，必須確認客戶的SYN（ack=j+1），同時自己也發(fā)送一個SYN包（syn=k）气忠，即SYN+ACK包，此時服務(wù)器進入SYN_RECV狀態(tài)赋咽；

第三次握手：客戶端收到服務(wù)器的SYN＋ACK包旧噪，向服務(wù)器發(fā)送確認包ACK(ack=k+1)，此包發(fā)送完畢脓匿，客戶端和服務(wù)器進入ESTABLISHED狀態(tài)淘钟，完成三次握手。握手完成后陪毡，兩臺主機開始傳輸數(shù)據(jù)了米母。

2018062310160639.png

為什么要三次握手？

如果只有一次握手毡琉，Client不能確定與Server的單向連接铁瞒，更加不能確定Server與Client的單向連接；
如果只有兩次握手桅滋，Client確定與Server的單向連接慧耍，但是Server不能確定與Client的單向連接；
只有三次握手丐谋，Client與Server才能相互確認雙向連接芍碧，實現(xiàn)雙工數(shù)據(jù)傳輸。

握手過程中傳送的包里不包含數(shù)據(jù)号俐，三次握手完畢后泌豆，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下吏饿，TCP連接一旦建立踪危，在通信雙方中的任何一方主動關(guān)閉連接之前蔬浙，TCP 連接都將被一直保持下去。斷開連接時服務(wù)器和客戶端均可以主動發(fā)起斷開TCP連接的請求陨倡，斷開過程需要經(jīng)過“四次揮手”敛滋。

20180623102043495.png

第一次揮手：
Client發(fā)送一個FIN，用來關(guān)閉Client到Server的數(shù)據(jù)傳送兴革，Client進入FIN_WAIT_1狀態(tài)绎晃。
第二次揮手：
Server收到FIN后，發(fā)送一個ACK給Client杂曲，確認序號為收到序號+1（與SYN相同庶艾，一個FIN占用一個序號），Server進入CLOSE_WAIT狀態(tài)擎勘。
第三次揮手：
Server發(fā)送一個FIN咱揍，用來關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進入LAST_ACK狀態(tài)棚饵。
第四次揮手：
Client收到FIN后煤裙，Client進入TIME_WAIT狀態(tài)，接著發(fā)送一個ACK給Server噪漾，確認序號為收到序號+1硼砰，Server進入CLOSED狀態(tài)，完成四次揮手欣硼。

為什么要四次揮手题翰？

“三次握手”的第二次握手發(fā)送SYN+ACK回應(yīng)第一次握手的SYN，但是“四次揮手”的第二次揮手只能發(fā)送ACK回應(yīng)第一次揮手的FIN诈胜，因為此時Server可能還有數(shù)據(jù)傳輸給Client豹障，所以Server傳輸數(shù)據(jù)完成后才能發(fā)起第三次揮手發(fā)送FIN給Client，等待Client的第四次揮手ACK焦匈。

https

http是超文本傳輸協(xié)議血公，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協(xié)議缓熟。HTTPS其實是有兩部分組成：HTTP +SSL/ TLS坞笙，也就是在HTTP上又加了一層處理加密信息的模塊。采用HTTPS協(xié)議的服務(wù)器必須要有一套數(shù)字證書荚虚，可以自己制作薛夜，也可以向組織申請。區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過版述，才可以繼續(xù)訪問梯澜，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務(wù))。這套證書其實就是一對公鑰和私鑰晚伙。SSL介于應(yīng)用層和TCP層之間吮龄。應(yīng)用層數(shù)據(jù)不再直接傳遞給傳輸層，而是傳遞給SSL層咆疗，SSL層對從應(yīng)用層收到的數(shù)據(jù)進行加密漓帚，并增加自己的SSL頭。

123.png

1. 客戶端發(fā)起HTTPS請求
2. 傳送證書
3. 客戶端解析證書
4. 傳送加密信息
5. 服務(wù)段解密信息
6. 傳輸加密后的信息
7. 客戶端解密信息

問題

1.怎么解決tcp拆包和黏包的問題
粘包午磁、拆包發(fā)生原因
發(fā)生TCP粘包或拆包有很多原因尝抖，現(xiàn)列出常見的幾點，可能不全面迅皇，歡迎補充昧辽，
1、要發(fā)送的數(shù)據(jù)大于TCP發(fā)送緩沖區(qū)剩余空間大小登颓，將會發(fā)生拆包搅荞。
2、待發(fā)送數(shù)據(jù)大于MSS（最大報文長度）框咙，TCP在傳輸前將進行拆包咕痛。
3、要發(fā)送的數(shù)據(jù)小于TCP發(fā)送緩沖區(qū)的大小喇嘱，TCP將多次寫入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去茉贡，將會發(fā)生粘包。
4婉称、接收數(shù)據(jù)端的應(yīng)用層沒有及時讀取接收緩沖區(qū)中的數(shù)據(jù)块仆，將發(fā)生粘包构蹬。
等等王暗。

粘包、拆包解決辦法
解決問題的關(guān)鍵在于如何給每個數(shù)據(jù)包添加邊界信息庄敛，常用的方法有如下幾個：

1俗壹、發(fā)送端給每個數(shù)據(jù)包添加包首部，首部中應(yīng)該至少包含數(shù)據(jù)包的長度藻烤，這樣接收端在接收到數(shù)據(jù)后绷雏，通過讀取包首部的長度字段，便知道每一個數(shù)據(jù)包的實際長度了怖亭。
2涎显、發(fā)送端將每個數(shù)據(jù)包封裝為固定長度（不夠的可以通過補0填充），這樣接收端每次從接收緩沖區(qū)中讀取固定長度的數(shù)據(jù)就自然而然的把每個數(shù)據(jù)包拆分開來兴猩。
3期吓、可以在數(shù)據(jù)包之間設(shè)置邊界，如添加特殊符號倾芝，這樣讨勤，接收端通過這個邊界就可以將不同的數(shù)據(jù)包拆分開箭跳。
等等。

2.upd丟包
1潭千、接收端處理時間過長導(dǎo)致丟包：調(diào)用recv方法接收端收到數(shù)據(jù)后谱姓，處理數(shù)據(jù)花了一些時間，處理完后再次調(diào)用recv方法刨晴，在這二次調(diào)用間隔里,發(fā)過來的包可能丟失屉来。對于這種情況可以修改接收端，將包接收后存入一個緩沖區(qū)割捅，然后迅速返回繼續(xù)recv奶躯。

2、發(fā)送的包巨大丟包：雖然send方法會幫你做大包切割成小包發(fā)送的事情亿驾，但包太大也不行嘹黔。例如超過50K的一個udp包，不切割直接通過send方法發(fā)送也會導(dǎo)致這個包丟失莫瞬。這種情況需要切割成小包再逐個send儡蔓。

3、發(fā)送的包較大疼邀，超過接受者緩存導(dǎo)致丟包：包超過mtu size數(shù)倍喂江，幾個大的udp包可能會超過接收者的緩沖，導(dǎo)致丟包旁振。這種情況可以設(shè)置socket接收緩沖获询。以前遇到過這種問題低淡，我把接收緩沖設(shè)置成64K就解決了论熙。

int nRecvBuf=32*1024;//設(shè)置為32K

setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));

4纬乍、發(fā)送的包頻率太快：雖然每個包的大小都小于mtu size 但是頻率太快志群，例如40多個mut size的包連續(xù)發(fā)送中間不sleep戒傻，也有可能導(dǎo)致丟包察纯。這種情況也有時可以通過設(shè)置socket接收緩沖解決频蛔，但有時解決不了夫凸。所以在發(fā)送頻率過快的時候還是考慮sleep一下吧甜攀。

5秋泄、局域網(wǎng)內(nèi)不丟包，公網(wǎng)上丟包规阀。這個問題我也是通過切割小包并sleep發(fā)送解決的恒序。如果流量太大，這個辦法也不靈了谁撼∑缧玻總之udp丟包總是會有的，如果出現(xiàn)了用我的方法解決不了，還有這個幾個方法： 要么減小流量与帆，要么換tcp協(xié)議傳輸了赌，要么做丟包重傳的工作。

一個是客戶端發(fā)送過快玄糟，網(wǎng)絡(luò)狀況不好或者超過服務(wù)器接收速度勿她，就會丟包。

第二個原因是服務(wù)器收到包后阵翎，還要進行一些處理逢并，而這段時間客戶端發(fā)送的包沒有去收，造成丟包郭卫。

那么需要做的是

客戶端降低發(fā)送速度砍聊，可以等待回包，或者加一些延遲贰军。服務(wù)器部分單獨開一個線程玻蝌，去接收UDP數(shù)據(jù)，存放在一個緩沖區(qū)中词疼，又另外的線程去處理收到的數(shù)據(jù)俯树，盡量減少因為處理數(shù)據(jù)延時造成的丟包。

有兩種方法解決UDP 丟包的問題：

方法一：重新設(shè)計一下協(xié)議贰盗，增加接收確認超時重發(fā)许饿。（推薦）

方法二：在接收方，將通信和處理分開舵盈，增加個應(yīng)用緩沖區(qū)陋率；如果有需要增加接收socket的系統(tǒng)緩沖區(qū)。（本方法不能從根本解決問題秽晚，只能改善）

https://baijiahao.baidu.com/s?id=1654225744653405133&wfr=spider&for=pc
http://www.reibang.com/p/066d99da7cbd
https://baijiahao.baidu.com/s?id=1654225744653405133&wfr=spider&for=pc
https://blog.csdn.net/qq_31337311/article/details/80781273
https://www.cnblogs.com/jiangzhaowei/p/8996810.html
http://blog.sina.com.cn/s/blog_d2bb5eff0102wbq2.html