一直用Http用多了 復(fù)習(xí)一下基礎(chǔ)
Unity通訊一般分為2類
Http : 應(yīng)用層 Unity內(nèi)置的UnityWebRequest類進(jìn)行通信（之前寫過一個分發(fā)器垃圾框架）用于交互量比較小
Socket：傳輸層 比較底層 實現(xiàn)TCP/UDP 用于頻繁的通信

這個是基于TCP 和IP傳輸不同消息

image.png

這個是三種常見的網(wǎng)絡(luò)層次劃分

image.png

image.png

物理層:中繼器、集線器 該層為上層協(xié)議提供了一個傳輸數(shù)據(jù)的可靠的物理媒體

數(shù)據(jù)鏈路層：網(wǎng)橋、交換機 數(shù)據(jù)鏈路層為網(wǎng)絡(luò)層提供可靠的數(shù)據(jù)傳輸

基本數(shù)據(jù)單位為幀
主要的協(xié)議：以太網(wǎng)協(xié)議

網(wǎng)絡(luò)層：路由器 網(wǎng)絡(luò)層負(fù)責(zé)對子網(wǎng)間的數(shù)據(jù)包進(jìn)行路由選擇，還可以實現(xiàn)擁塞控制、網(wǎng)際互連等功能；

基本數(shù)據(jù)單位為IP數(shù)據(jù)報；
IP協(xié)議（Internet Protocol，因特網(wǎng)互聯(lián)協(xié)議）
ICMP協(xié)議（Internet Control Message Protocol，因特網(wǎng)控制報文協(xié)議）
ARP協(xié)議（Address Resolution Protocol，地址解析協(xié)議）
RARP協(xié)議（Reverse Address Resolution Protocol，逆地址解析協(xié)議）

傳輸層：網(wǎng)關(guān) 傳輸層負(fù)責(zé)將上層數(shù)據(jù)分段并提供端到端的、可靠的或不可靠的傳輸以及端到端的差錯控制和流量控制問題

包含的主要協(xié)議：TCP協(xié)議（Transmission Control Protocol，傳輸控制協(xié)議）、UDP協(xié)議（User Datagram Protocol，用戶數(shù)據(jù)報協(xié)議）

會話層：主機 負(fù)責(zé)建立、管理、終止進(jìn)程之間的會話

表示層： 數(shù)據(jù)的加密、壓縮、格式轉(zhuǎn)換等

應(yīng)用層：為操作系統(tǒng)或網(wǎng)絡(luò)應(yīng)用程序提供訪問網(wǎng)絡(luò)服務(wù)的接口。

數(shù)據(jù)傳輸基本單位為報文
包含的主要協(xié)議：
FTP（文件傳送協(xié)議）、Telnet（遠(yuǎn)程登錄協(xié)議）、DNS（域名解析協(xié)議）、SMTP（郵件傳送協(xié)議），POP3協(xié)議（郵局協(xié)議），HTTP協(xié)議（Hyper Text Transfer Protocol）。

IP地址

分配給用戶上網(wǎng)使用的網(wǎng)際協(xié)議
目前IPv4多 比如192.168.1.1
新的IPv6(因為IPv4數(shù)量不夠分配)如3ffe:3201:1401:1280:c8ff:fe4d:db39:1984。

TCP/IP協(xié)議

Internet最基本的協(xié)議
TCP負(fù)責(zé)發(fā)現(xiàn)傳輸?shù)膯栴}，一有問題就發(fā)出信號，要求重新傳輸，直到所有數(shù)據(jù)安全正確地傳輸?shù)侥康牡亍?br> 可靠的協(xié)議 通過三次握手建立的面向連接通信協(xié)議

image.png

3次握手 四次揮手 實習(xí)生?？?br> TCP連接建立過程(三次握手)：
1.首先Client端發(fā)送連接請求報文
2.Server段接受連接后回復(fù)ACK報文，并為這次連接分配資源。
3.Client端接收到ACK報文后也向Server段發(fā)生ACK報文，并分配資源，這樣TCP連接就建立了。
TCP連接斷開過程(四次揮手)：
1.Client端發(fā)起中斷連接請求(FIN報文)
2.Server端接到FIN報文后，發(fā)送ACK服務(wù)器還有消息沒發(fā)完讓Client待命，Client端就進(jìn)入FIN_WAIT，繼續(xù)等待Server端的FIN報文
3.Server端確定數(shù)據(jù)已發(fā)送完成，則向Client端發(fā)送FIN報文，
4.Client端收到FIN報文后發(fā)送ACK后進(jìn)入TIME_WAIT狀態(tài)，如果Server端沒有收到ACK則可以重傳，Server端收到ACK后 關(guān)閉，Client等待了2MSL后依然沒有收到回復(fù)客戶端也關(guān)閉
SYN:"synchronize"請求同步標(biāo)志；；ACK:"acknowledge"確認(rèn)標(biāo)志"；FIN："Finally"結(jié)束標(biāo)志。

image.png

為什么要三次握手？
防止因為網(wǎng)卡導(dǎo)致Sever收到多次Client請求 建立N個監(jiān)聽 造成資源浪費
為什么要四次揮手？
自己不請求直接關(guān)閉 但是服務(wù)器還能給你發(fā)數(shù)據(jù) 服務(wù)器浪費資源 而且客戶端也會強行接收
使用TCP的協(xié)議：FTP（文件傳輸協(xié)議）、Telnet（遠(yuǎn)程登錄協(xié)議）、SMTP（簡單郵件傳輸協(xié)議）、POP3（和SMTP相對，用于接收郵件）、HTTP協(xié)議等。

UDP

面向無連接的通訊協(xié)議
UDP通訊時不需要接收方確認(rèn)，屬于不可靠的傳輸 會丟包
UDP與TCP位于同一層，但它不管數(shù)據(jù)包的順序、錯誤或重發(fā)
主要用于面向查詢---應(yīng)答的程序
每個UDP報文分UDP報頭和UDP數(shù)據(jù)區(qū)兩部分
UDP報頭由4個域組成，其中每個域各占用2個字節(jié)
（1）源端口號；
（2）目標(biāo)端口號；
（3）數(shù)據(jù)報長度；
（4）校驗值。

使用UDP協(xié)議包括：TFTP（簡單文件傳輸協(xié)議）、SNMP（簡單網(wǎng)絡(luò)管理協(xié)議）、DNS（域名解析協(xié)議）、NFS、BOOTP。

HTTP協(xié)議

超文本傳輸協(xié)議（HTTP，HyperText Transfer Protocol)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議

image.png

HTTP協(xié)議特點：
簡單快速 靈活 無連接 無狀態(tài) 支持B/S(瀏覽器/服務(wù)器)及C/S(客戶端/服務(wù)器)模式。
URL

image.png

Socket 套接字

和服務(wù)器有一些頻繁的交互 用http時不時請求 叫輪詢 效率低下
soket可以理解為插座 插頭接上了可以保持通信

端口:
每個Socket連接都是從一臺計算機網(wǎng)卡的一個端口連接到另外一臺計算機網(wǎng)卡的某個端口。
IP是房子的話 端口就是門
TCP端口和UDP端口相互獨立 如TCP255端口 和UDP255端口 不沖突

周知端口
范圍從0到1023，其中80端口分配給WWW服務(wù)，21端口分配給FTP服務(wù)等。
瀏覽器的地址欄里輸入一個網(wǎng)址的時候是不必指定端口號的，因為在默認(rèn)情況下WWW服務(wù)的端口是“80”。
網(wǎng)絡(luò)服務(wù)是可以使用其他端口號的 比如 網(wǎng)址：8080
但是有些系統(tǒng)協(xié)議使用固定的端口號，它是不能被改變的，比如139 端口專門用于NetBIOS與TCP/IP之間的通信，不能手動改變。
自己開發(fā)時盡量不要使用1024之下的端口，可能會與系統(tǒng)端口沖突。

TCP協(xié)議流程

image.png

服務(wù)端:
創(chuàng)建socket對象
bind：綁定IP地址和端口
listen：開始監(jiān)聽綁定的IP地址和端口，等待客戶端的連接
accept：如果有客戶端發(fā)起連接，通過accept接受連接請求，連接成功后會復(fù)制一個socket出來用于和當(dāng)前接受連接的客戶端進(jìn)行通信。(服務(wù)端最初創(chuàng)建的那個socket只是用來監(jiān)聽并建立連接用的，實際和客戶端通信并不是最初的socket，而是在accept這一步會自動創(chuàng)建一個新的socket出來和客戶端通信。)
read/write：使用新的socket讀寫數(shù)據(jù)
close：關(guān)閉socket，如果關(guān)閉的是服務(wù)端的監(jiān)聽socket，則無法接收新的連接，但是已經(jīng)創(chuàng)建的和客戶端的連接不會被關(guān)閉。
客戶端:
創(chuàng)建socket對象
connect：連接服務(wù)端，連接成功后系統(tǒng)會自動分配端口
read/write：連接成功后，就可以進(jìn)行數(shù)據(jù)的讀寫了，這里讀寫使用的socket還是第一步創(chuàng)建的socket對象。
close：關(guān)閉連接。
如果收到了長度為0的數(shù)據(jù)，則代表遠(yuǎn)程socket關(guān)閉了連接。

UDP協(xié)議流程

image.png

服務(wù)器:
創(chuàng)建socket對象
bind：綁定IP和端口，用于接收數(shù)據(jù)（注意這里綁定完就可以直接接收數(shù)據(jù)了，并不需要等待連接）
read/write：讀寫數(shù)據(jù)
客戶端:
創(chuàng)建socket對象
read/write：讀寫數(shù)據(jù)，不需要先建立連接，直接給對應(yīng)的IP+端口發(fā)送數(shù)據(jù)即可。

由于沒有建立連接以及連接的保障，UDP在傳輸效率上會很高
UDP有一個功能是TCP所不具備的，那就是廣播功能（UDP可以將消息發(fā)送到在同一廣播網(wǎng)絡(luò)上的每個主機 CS、魔獸爭霸局域網(wǎng)對戰(zhàn)）。

如何選擇協(xié)議

HTTP/HTTPS(比http更安全):小游戲 網(wǎng)頁 間歇性發(fā)送鏈接 偶爾延遲。
TCP長連接： 卡牌游戲 某些mmo 客戶端和服務(wù)器都可以獨立發(fā)包 偶爾延遲
UDP：動作游戲 mmo 槍戰(zhàn) 客戶端和服務(wù)器都可以獨立發(fā)包 無法接受延遲

可以混合使用你的MMO客戶端也許首先使用HTTP去獲取上一次的更新內(nèi)容，然后使用UDP跟游戲服務(wù)器進(jìn)行連接。
現(xiàn)在也有kcp 就是tcp和udp結(jié)合 快速安全可靠

TCP優(yōu)勢 劣勢

簡單直接的長連接
可靠的信息傳輸
數(shù)據(jù)包的大小沒有限制

坑多 斷線檢測、慢速客戶端響應(yīng)阻塞數(shù)據(jù)包，對開放連接的各種dos攻擊，阻塞和非阻塞IO模型
丟包會有阻塞機制(一般是重發(fā) tcp相反) 所以手機游戲ping跳1000就這個原因

UDP 優(yōu)勢 劣勢

只使用一個socket進(jìn)行通信
快速
基于數(shù)據(jù)包構(gòu)建
靈活 多種方式處理延遲

很多東西沒有要自己構(gòu)建
不可靠
丟包

選擇問題

客戶端直接開始進(jìn)行計算而不等待服務(wù)端確認(rèn)是一種典型的隱藏延遲的技術(shù)(容易被抓包篡改)。
我們到底是使用TCP還是UDP取決于我們能否隱藏延遲。
比如TCP 在棋牌 卡牌游戲 卡1S無所謂 在動作游戲moba游戲就很致命
可靠的UDP/kcp和TCP不一樣，要去實現(xiàn)一個特殊的阻塞控制，而且還要保證可靠性，也可以使用許多支持可靠通信的UDP庫，但是庫一般為了通用會降低某種新能，自己根據(jù)項目情況寫可以發(fā)揮到極致
如果不知道用什么就TCP