**

1、網(wǎng)絡(luò)基礎(chǔ)知識

**

1.1> 什么是OSI模型

OSI 模型(Open System Interconnection model)是一個由國際標準化組織?提出的概念模型,試圖?供一個使各種不同的計算機和網(wǎng)絡(luò)在世界范圍內(nèi)實現(xiàn)互聯(lián)的標準框架。
它將計算機網(wǎng)絡(luò)體系結(jié)構(gòu)劃分為七層,每層都可以提供抽象良好的接口。了解 OSI 模型有助于理解實際上互聯(lián)網(wǎng)絡(luò)的工業(yè)標準——TCP/IP 協(xié)議。

1.2> OSI模型介紹

物理層：
物理層負責最后將信息編碼成電流脈沖或其它信號用于網(wǎng)上傳輸；
eg：RJ45等將數(shù)據(jù)轉(zhuǎn)化成0和1；

數(shù)據(jù)鏈路層:
數(shù)據(jù)鏈路層通過物理網(wǎng)絡(luò)鏈路?供數(shù)據(jù)傳輸。不同的數(shù)據(jù)鏈路層定義了不同的網(wǎng)絡(luò)和協(xié) 議特征,其中包括物理編址、網(wǎng)絡(luò)拓撲結(jié)構(gòu)、錯誤校驗、數(shù)據(jù)幀序列以及流控;
可以簡單的理解為：規(guī)定了0和1的分包形式，確定了網(wǎng)絡(luò)數(shù)據(jù)包的形式；

網(wǎng)絡(luò)層:
網(wǎng)絡(luò)層負責在源和終點之間建立連接;
可以理解為，此處需要確定計算機的位置，怎么確定？IPv4，IPv6！

傳輸層
傳輸層向高層?提供可靠的端到端的網(wǎng)絡(luò)數(shù)據(jù)流服務(wù)。
可以理解為：每一個應(yīng)用程序都會在網(wǎng)卡注冊一個端口號，該層就是端口與端口的通信！常用的（TCP／IP）協(xié)議；

會話層
會話層建立、管理和終止表示層與實體之間的通信會話；
建立一個連接（自動的手機信息、自動的網(wǎng)絡(luò)尋址）;

表示層:
表示層提供多種功能用于應(yīng)用層數(shù)據(jù)編碼和轉(zhuǎn)化,以確保以一個系統(tǒng)應(yīng)用層發(fā)送的信息 可以被另一個系統(tǒng)應(yīng)用層識別;
可以理解為：解決不同系統(tǒng)之間的通信，eg：Linux下的QQ和Windows下的QQ可以通信；

應(yīng)用層:
OSI 的應(yīng)用層協(xié)議包括文件的傳輸、訪問及管理協(xié)議(FTAM) ,以及文件虛擬終端協(xié)議(VIP)和公用管理系統(tǒng)信息(CMIP)等;
規(guī)定數(shù)據(jù)的傳輸協(xié)議；

常見的應(yīng)用層協(xié)議

互聯(lián)網(wǎng)分層結(jié)構(gòu)的好處: 上層的變動完全不影響下層的結(jié)構(gòu)。

1.4> TCP/IP 協(xié)議基本概念

OSI 模型所分的七層,在實際應(yīng)用中,往往有一些層被整合,或者功能分散到其他層去。TCP/IP 沒有照搬 OSI 模型,也沒有 一個公認的 TCP/IP 層級模型,一般劃分為三層到五層模型來描述 TCP/IP 協(xié)議。

• 在此描述用一個通用的四層模型來描述,每一層都和 OSI 模型有較強的相關(guān)性但是又可能會有交叉
• TCP/IP 的設(shè)計,是吸取了分層模型的精華思想——封裝。每層對上一層?供服務(wù)的時 候,上一層的數(shù)據(jù)結(jié)構(gòu)是黑盒,直接作為本層的數(shù)據(jù),而不需要關(guān)心上一層協(xié)議的任何細節(jié)

TCP/IP 分層模型的分層以以太網(wǎng)上傳輸 UDP 數(shù)據(jù)包如圖所示;

1.5> 四層模型介紹

網(wǎng)絡(luò)接口層
網(wǎng)絡(luò)接口層包括用于協(xié)作IP數(shù)據(jù)在已有網(wǎng)絡(luò)介質(zhì)上傳輸?shù)膮f(xié)議。
它定義像地址解析協(xié)議(Address Resolution Protocol,ARP)這樣的協(xié)議,?供 TCP/IP 協(xié)議的數(shù)據(jù)結(jié)構(gòu)和實際物理硬件之間的接口。
可以理解為：確定了網(wǎng)絡(luò)數(shù)據(jù)包的形式。

網(wǎng)間層
網(wǎng)間層對應(yīng)于 OSI 七層參考模型的網(wǎng)絡(luò)層，本層包含 IP 協(xié)議、RIP 協(xié)議(Routing Information Protocol,路由信息協(xié)議),負責數(shù)據(jù)的包裝、尋址和路由。同時還包含網(wǎng)間控制報文協(xié)議(Internet Control Message Protocol,ICMP)用來?供網(wǎng)絡(luò)診斷信息；
可以理解為：該層時確定計算機的位置。

傳輸層
傳輸層對應(yīng)于 OSI 七層參考模型的傳輸層,它?供兩種端到端的通信服務(wù)。其中 TCP 協(xié)議(Transmission Control Protocol)提供可靠的數(shù)據(jù)流運輸服務(wù),UDP 協(xié)議(Use Datagram Protocol)提供不可靠的用戶數(shù)據(jù)報服務(wù)。
TCP:三次握手、四次揮手;UDP:只發(fā)不管別人收不收得到–任性哈

應(yīng)用層
應(yīng)用層對應(yīng)于 OSI 七層參考模型的應(yīng)用層和表達層；
不明白的再看看7層參考模型的描述。

1.6> 數(shù)據(jù)包

寬泛意義的數(shù)據(jù)包:每一個數(shù)據(jù)包都包含"標頭"和"數(shù)據(jù)"兩個部分."標頭"包含本數(shù)據(jù)包的一些說明."數(shù)據(jù)"則是本數(shù)據(jù)包的內(nèi)容.

細分數(shù)據(jù)包：

應(yīng)用程序數(shù)據(jù)包: 標頭部分規(guī)定應(yīng)用程序的數(shù)據(jù)格式.數(shù)據(jù)部分傳輸具體的數(shù)據(jù)內(nèi)容. ——對應(yīng)下圖中的數(shù)據(jù)！

TCP/UDP數(shù)據(jù)包:標頭部分包含雙方的發(fā)出端口和接收端口. UDP數(shù)據(jù)包:'標頭’長度:8個字節(jié),"數(shù)據(jù)包"總長度最大為65535字節(jié),正好放進一個IP數(shù)據(jù)包. TCP數(shù)據(jù)包:理論上沒有長度限制,但是,為了保證網(wǎng)絡(luò)傳輸效率,通常不會超過IP數(shù)據(jù)長度,確保單個包不會被分割. ——對應(yīng)下圖中的UDP數(shù)據(jù)！

IP數(shù)據(jù)包: 標頭部分包含通信雙方的IP地址,協(xié)議版本,長度等信息. '標頭’長度:20~60字節(jié),"數(shù)據(jù)包"總長度最大為65535字節(jié). ——對應(yīng)下圖中的IP數(shù)據(jù)

以太網(wǎng)數(shù)據(jù)包: 最基礎(chǔ)的數(shù)據(jù)包.標頭部分包含了通信雙方的MAC地址,數(shù)據(jù)類型等. '標頭’長度:18字節(jié),'數(shù)據(jù)’部分長度:46~1500字節(jié). ——對應(yīng)下圖中的以太網(wǎng)數(shù)據(jù)

UDP（User Datagram protocol）用戶數(shù)據(jù)報協(xié)議，它只提供應(yīng)用進程尋址和簡單的差錯檢測，并不提供其他功能。

TCP（Transmission Control Protocol，傳輸控制協(xié)議）是面向連接的協(xié)議，也就是說，在收發(fā)數(shù)據(jù)前，必須和對方建立可靠的連接。一個TCP連接必須要經(jīng)過三次“對話”才能建立起來，其中的過程非常復雜，只簡單的描述下這三次對話的簡單過程：主機A向主機B發(fā)出連接請求數(shù)據(jù)包：“我想給你發(fā)數(shù)據(jù)，可以嗎？”，這是第一次對話；主機B向主機A發(fā)送同意連接和要求同步（同步就是兩臺主機一個在發(fā)送，一個在接收，協(xié)調(diào)工作）的數(shù)據(jù)包：“可以，你什么時候發(fā)？”，這是第二次對話；主機A再發(fā)出一個數(shù)據(jù)包確認主機B的要求同步：“我現(xiàn)在就發(fā)，你接著吧！”，這是第三次對話。三次“對話”的目的是使數(shù)據(jù)包的發(fā)送和接收同步，經(jīng)過三次“對話”之后，主機A才向主機B正式發(fā)送數(shù)據(jù)。

**

2、TCP/IP 協(xié)議族

**

2.1> TCP/IP 協(xié)議族常用協(xié)議

應(yīng)用層：TFTP，HTTP，SNMP，FTP，SMTP，DNS，Telnet 等等
傳輸層：TCP，UDP
網(wǎng)絡(luò)層：IP，ICMP，OSPF，EIGRP，IGMP
數(shù)據(jù)鏈路層：SLIP，CSLIP，PPP，MTU

• 重要的 TCP/IP 協(xié)議族協(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é)議;

TCP(TransmissionControlProtocol,傳輸控制協(xié)議)是一種面向連接的,可靠的, 基于字節(jié)流傳輸?shù)耐ㄐ艆f(xié)議。TCP 具有端口號的概念,用來標識同一個地址上的不 同應(yīng)用。?述 TCP 的標準文檔是 RFC793。

UDP(UserDatagramProtocol,用戶數(shù)據(jù)報協(xié)議)是一個面向數(shù)據(jù)報的傳輸層協(xié) 議。UDP 的傳輸是不可靠的,簡單的說就是發(fā)了不管,發(fā)送者不會知道目標地址 的數(shù)據(jù)通路是否發(fā)生擁塞,也不知道數(shù)據(jù)是否到達,是否完整以及是否還是原來的 次序。它同 TCP 一樣有用來標識本地應(yīng)用的端口號。所以應(yīng)用 UDP 的應(yīng)用,都能 夠容忍一定數(shù)量的錯誤和丟包,但是對傳輸性能敏感的,比如流媒體、DNS 等。

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ò)引導計算機過程中傳輸引導文件等小文件;

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。

2.2> TCP &UDP

TCP提供一對一的、面向連接的可靠通信服務(wù)。TCP建立連接，對發(fā)送的數(shù)據(jù)包進行排序和確認，并恢復在傳輸過程中丟失的數(shù)據(jù)包。與TCP不同，UDP提供一對一或一對多的、無連接的不可靠通信服務(wù)。
不論是TCP/IP還是在OSI參考模型中，任意相鄰兩層的下層為服務(wù)提供者，上層為服務(wù)調(diào)用者。下層為上層提供的服務(wù)可分為兩類：面向連接服務(wù)和無連接服務(wù)。

面向連接的網(wǎng)絡(luò)服務(wù)(TCP)

面向連接的網(wǎng)絡(luò)服務(wù)又稱為虛電路（Virtual
Circuit）服務(wù)，它具有網(wǎng)絡(luò)連接建立、數(shù)據(jù)傳輸和網(wǎng)絡(luò)連接釋放三個階段。是按順序傳輸可靠的報文分組方式，適用于指定對象、長報文、會話型傳輸要求。
&
面向連接服務(wù)以電話系統(tǒng)為模式。要和某個人通話，首先拿起電話，撥號碼，通話，然后掛斷。同樣在使用面向連接的服務(wù)時，用戶首先要建立連接，使用連接，然后釋放連接。連接本質(zhì)上像個管道：發(fā)送者在管道的一端放入物體，接收者在另一端按同樣的次序取出物體；其特點是收發(fā)的數(shù)據(jù)不僅順序一致，而且內(nèi)容也相同。–類似打電話

無連接的網(wǎng)絡(luò)服務(wù)

無連接網(wǎng)絡(luò)服務(wù)的兩實體之間的通信不需要事先建立好一個連接。無連接網(wǎng)絡(luò)服務(wù)有3種類型：數(shù)據(jù)報（Datagram）、確認交付（Confirmed
Delivery）與請求回答（Request reply）。

無連接服務(wù)以郵政系統(tǒng)為模式。每個報文（信件）帶有完整的目的地址，并且每一個報文都獨立于其他報文，由系統(tǒng)選定的路線傳遞。在正常情況下，當兩個報文發(fā)往同一目的地時，先發(fā)的先到。但是，也有可能先發(fā)的報文在途中延誤了，后發(fā)的報文反而先收到；而這種情況在面向連接的服務(wù)中是絕對不可能發(fā)生的。–類似發(fā)短信

TCP的優(yōu)缺點

從原理上，TCP的優(yōu)勢有：

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

TCP最糟糕的特性是它對阻塞的控制。
一般來說，TCP假定丟包是由于網(wǎng)絡(luò)帶寬不夠造成的，所以發(fā)生這種情況的時候，TCP就會減少發(fā)包速度。

在3G或WiFi下，一個數(shù)據(jù)包丟失了，你希望的是立馬重發(fā)這個數(shù)據(jù)包，然而TCP的阻塞機制卻完全是采用相反的方式來處理！

而且沒有任何辦法能夠繞過這個機制，因為這是TCP協(xié)議構(gòu)建的基礎(chǔ)。這就是為什么在3G或者WiFi環(huán)境下，ping值能夠上升到1000多毫秒的原因。

一個采用TCP的游戲必須能夠處理好突發(fā)的延遲問題（紙牌客戶端就很典型，對突發(fā)性的一秒的延遲，玩家也不會產(chǎn)生什么抱怨）或者是擁有緩解延遲問題的好方法。
魔獸世界中是有多重連接的, 應(yīng)該是UDP和TCP共用的, UDP用于不要求數(shù)據(jù)可靠的數(shù)據(jù), TCP用于傳輸有可靠性要求的數(shù)據(jù).
例如周圍人物的動向，NPC移動，技能動畫指令等則可以使用UDP，這個UDP并不保證可靠，但丟包影響不大。對于技能,
金錢，經(jīng)驗等重要的人物數(shù)據(jù), 必須通過TCP保證.

UDP的優(yōu)缺點

UDP （User Datagram Protocol，用戶數(shù)據(jù)報協(xié)議），是OSI（Open System Interconnection，開放式系統(tǒng)互聯(lián)） 參考模型中一種無連接的傳輸層協(xié)議，提供面向事務(wù)的簡單不可靠信息傳送服務(wù)，

UDP是基于數(shù)據(jù)包構(gòu)建，這意味著在某些方面需要你完全顛覆在TCP下的觀念。UDP只使用一個socket進行通信，不像TCP需要為每一個客戶端建立一個socket連接。

在選擇使用協(xié)議的時候，選擇UDP必須要謹慎。
在網(wǎng)絡(luò)質(zhì)量令人十分不滿意的環(huán)境下，UDP協(xié)議數(shù)據(jù)包丟失會比較嚴重。
但是由于UDP的特性：它不屬于連接型協(xié)議，因而具有資源消耗小，處理速度快的優(yōu)點，
所以通常音頻、視頻和普通數(shù)據(jù)在傳送時使用UDP較多，因為它們即使偶爾丟失一兩個數(shù)據(jù)包，也不會對接收結(jié)果產(chǎn)生太大影響。比如我們聊天用的ICQ和QQ就是使用的UDP協(xié)議。

那么到底是用UDP還是TCP呢？

• 如果是由客戶端間歇性的發(fā)起無狀態(tài)的查詢，并且偶爾發(fā)生延遲是可以容忍，那么使用HTTP/HTTPS吧。
• 如果客戶端和服務(wù)器都可以獨立發(fā)包，但是偶爾發(fā)生延遲可以容忍（比如：在線的紙牌游戲，許多MMO類的游戲），那么使用TCP長連接吧。
• 如果客戶端和服務(wù)器都可以獨立發(fā)包，而且無法忍受延遲（比如：大多數(shù)的多人動作類游戲，一些MMO類游戲），那么使用UDP吧。

這些也應(yīng)該考慮在內(nèi)：你的MMO客戶端也許首先使用HTTP去獲取上一次的更新內(nèi)容，然后使用UDP跟游戲服務(wù)器進行連接。

2.3> TCP 工作原理

TCP–傳輸控制協(xié)議
TCP全稱是Transmission Control Protocol，中文名為傳輸控制協(xié)議，它可以提供可靠的、面向連接的網(wǎng)絡(luò)數(shù)據(jù)傳遞服務(wù)。

• 傳輸控制協(xié)議主要包含下列任務(wù)和功能：
  確保IP數(shù)據(jù)報的成功傳遞。
  對程序發(fā)送的大塊數(shù)據(jù)進行分段和重組。
  確保正確排序及按順序傳遞分段的數(shù)據(jù)。
  通過計算校驗和，進行傳輸數(shù)據(jù)的完整性檢查。
  根據(jù)數(shù)據(jù)是否接收成功發(fā)送肯定消息。通過使用選擇性確認，也對沒有收到的數(shù)據(jù)發(fā)送否定確認。
  為必須使用可靠的、基于會話的數(shù)據(jù)傳輸程序，如客戶端/服務(wù)器數(shù)據(jù)庫和電子郵件程序，提供首選傳輸方法。

TCP工作原理
TCP的連接建立過程又稱為TCP三次握手;
首先發(fā)送方主機向接收方主機發(fā)起一個建立連接的同步（SYN）請求；
接收方主機在收到這個請求后向發(fā)送方主機回復一個同步/確認（SYN/ACK）應(yīng)答；
發(fā)送方主機收到此包后再向接收方主機發(fā)送一個確認（ACK），此時TCP連接成功建立.
一旦初始的三次握手完成，在發(fā)送和接收主機之間將按順序發(fā)送和確認段。關(guān)閉連接之前，TCP使用類似的握手過程驗證兩個主機是否都完成發(fā)送和接收全部數(shù)據(jù)。
完成三次握手，客戶端與服務(wù)器開始傳送數(shù)據(jù)。

HTTP(Hypertext Transfer Protocol)超文本傳輸協(xié)議(80)

1).請求報文:請求行 － 通用信息頭 － 請求頭 － 實體頭 － 報文主體
2).應(yīng)答報文:狀態(tài)行 － 通用信息頭 － 響應(yīng)頭 － 實體頭－ 報文主體
3).訪問過程如下

HTTP+TCP網(wǎng)絡(luò)傳輸示意圖：

TCP協(xié)議的三次握手與四次關(guān)閉詳解，傳送門

IP數(shù)據(jù)包和TCP／UDP的數(shù)據(jù)包

2.4> HTTP協(xié)議常用狀態(tài)碼

4).狀態(tài)碼A).1xx:指示信息--表示請求已接收，繼續(xù)處理100——客戶必須繼續(xù)發(fā)出請求101——客戶要求服務(wù)器根據(jù)請求轉(zhuǎn)換HTTP協(xié)議版本B).2xx:成功--表示請求已被成功接收、理解、接受200——請求成功201——提示知道新文件的URL202——接受和處理、但處理未完成203——返回信息不確定或不完整204——請求收到，但返回信息為空205——服務(wù)器完成了請求，用戶代理必須復位當前已經(jīng)瀏覽過的文件206——服務(wù)器已經(jīng)完成了部分用戶的GET請求C).3xx:重定向--要完成請求必須進行更進一步的操作300——請求的資源可在多處得到301——刪除請求數(shù)據(jù)302——在其他地址發(fā)現(xiàn)了請求數(shù)據(jù)303——建議客戶訪問其他URL或訪問方式304——客戶端已經(jīng)執(zhí)行了GET，但文件未變化305——請求的資源必須從服務(wù)器指定的地址得到306——前一版本HTTP中使用的代碼，現(xiàn)行版本中不再使用307——申明請求的資源臨時性刪除D).4xx:客戶端錯誤--請求有語法錯誤或請求無法實現(xiàn)400——錯誤請求，如語法錯誤401——請求授權(quán)失敗402——保留有效ChargeTo頭響應(yīng)403——請求不允許404——沒有發(fā)現(xiàn)文件、查詢或URl405——用戶在Request-Line字段定義的方法不允許406——根據(jù)用戶發(fā)送的Accept拖，請求資源不可訪問407——類似401，用戶必須首先在代理服務(wù)器上得到授權(quán)408——客戶端沒有在用戶指定的餓時間內(nèi)完成請求409——對當前資源狀態(tài)，請求不能完成410——服務(wù)器上不再有此資源且無進一步的參考地址411——服務(wù)器拒絕用戶定義的Content-Length屬性請求412——一個或多個請求頭字段在當前請求中錯誤413——請求的資源大于服務(wù)器允許的大小414——請求的資源URL長于服務(wù)器允許的長度415——請求資源不支持請求項目格式416——請求中包含Range請求頭字段，在當前請求資源范圍內(nèi)沒有range指示值，請求也不包含If-Range請求頭字段417——服務(wù)器不滿足請求Expect頭字段指定的期望值，如果是代理服務(wù)器，可能是下一級服務(wù)器不能滿足請求E).5xx:服務(wù)器端錯誤--服務(wù)器未能實現(xiàn)合法的請求500——服務(wù)器產(chǎn)生內(nèi)部錯誤501——服務(wù)器不支持請求的函數(shù)502——服務(wù)器暫時不可用，有時是為了防止發(fā)生系統(tǒng)過載503——服務(wù)器過載或暫停維修504——關(guān)口過載，服務(wù)器使用另一個關(guān)口或服務(wù)來響應(yīng)用戶，等待時間設(shè)定值較長505——服務(wù)器不支持或拒絕支請求頭中指定的HTTP版本　　　　　　

HTTPS(Hypertext Transfer Protocol Secure)超文本傳輸安全協(xié)議(443)

1).HTTP+SSL(Netscape的安全套接層)
a).SSL((Secure Sockets Layer) 安全套接層(40-128)
b).TLS(Transport Layer Security) 傳輸層安全 2).數(shù)據(jù)加密(SSL);身份認證(CA證書)

TCP(Transmission Control Protocol)傳輸控制協(xié)議

1).面向連接
2).可靠傳輸?shù)那闆r, 應(yīng)用于文件傳輸, 重要狀態(tài)更新等場景
3).傳輸大量數(shù)據(jù)
4).傳輸慢

UDP(User Data Protocol)用戶數(shù)據(jù)協(xié)議

1).面向非連接
2).高速傳輸和實時性要求較高的通信領(lǐng)域(可靠性需要應(yīng)用層控制)
3).傳輸少量數(shù)據(jù)
4).傳輸快

**

三、Socket

**

3.1> Socket 簡介

Socket起源于 20 世 紀 80 年代早期,最早由 4.1c BSD UNIX 引入,所以也稱之為“BSD Socket 或者 Berkeley Socket”。BSD Socket 是事實上的網(wǎng)絡(luò)應(yīng)用編程接口標準,其它編程語言往往也是用與這套（用C寫成的編程接口）類似接口。
用 Socket 能夠?qū)崿F(xiàn)網(wǎng)絡(luò)上的不同主機之間或同一主機的不同對象之間的數(shù)據(jù)通信。所以,現(xiàn)在 Socket 已經(jīng)是一類通用通信接口的集合。
大的類型可以分為網(wǎng)絡(luò) Socket 和本地 Socket 兩種。

本地上的兩個進程如何通信?

• 內(nèi)存共享(munmap())；
• 消息和隊列
• 管道(匿名管道pipe()和命名管道m(xù)kfifo())；
• 信號量（P V操作）;
• RPC remote protocol control
• 本地Socket;

網(wǎng)路上的兩個進程如何通信？

本地進程間通信(IPC)通過PID(在終端中輸入ps-ef可查看PID)可以唯一確定彼此，然后通過共享內(nèi)存，消息隊列來通;
網(wǎng)絡(luò)上的兩個進程確定彼此需要IP與端口號，通過傳輸層(TCP/UDP)協(xié)議進行通信；
這就是網(wǎng)絡(luò) Socket 。 socket可以理解為：在TCP/UDP 加一個端口綁定。

網(wǎng)絡(luò)socket和 本地 Socket對比

在同一個設(shè)備上，兩個進程如果需要進行通訊最基本的一個前提能能夠唯一的標示一個進程，在本地進程通訊中可以使用PID來唯一標示一個進程；

PID只在本地唯一，網(wǎng)絡(luò)中的兩個進程PID沖突幾率很大，此時顯然不行了，怎么辦？
IP層的ip地址可以唯一標示主機，而TCP層協(xié)議和端口號可以唯一標示主機的一個進程，所以可以利用ip地址＋協(xié)議＋端口號唯一標示網(wǎng)絡(luò)中的一個進程。

Socket通信就是一種確定了端口號的TCP/IP通信，或者說Socket通信與IP通信差別就是端口確定，協(xié)議確定。

用一張圖表達一下：

端口的打開是雙方的，在C/S（Client&&Server）結(jié)構(gòu)的TCP連接中不僅僅要注意到S的端口(監(jiān)聽的)，實際上C也開了一個端口，而C端的端口是動態(tài)端口，TCP連接建立的時候，C端的端口會在三次握手結(jié)束后確定，動態(tài)打開一個,這個端口不受用戶/程序員的控制。

Socket 代碼編寫步驟
創(chuàng)建客戶端Socket
創(chuàng)建服務(wù)器Socket
連接到服務(wù)器(Socket編程)
發(fā)送數(shù)據(jù)給服務(wù)器
接收服務(wù)器返回的數(shù)據(jù)
關(guān)閉Socket : close(socketNumber)

一張經(jīng)典的Socket C/S的步驟圖。

3.2> Socket編程優(yōu)劣勢

1).socket本質(zhì)是編程接口(API),對TCP/IP的封裝,TCP/IP也要提供可供程序員做網(wǎng)絡(luò)開發(fā)所用的接口，這就是Socket編程接口
2).連接過程:服務(wù)器監(jiān)聽，客戶端請求，連接確認
3).優(yōu)勢與劣勢
A).優(yōu)勢:

a).傳輸數(shù)據(jù)為字節(jié)級，傳輸數(shù)據(jù)可自定義，數(shù)據(jù)量小b).傳輸數(shù)據(jù)時間短，性能高c).適合于客戶端和服務(wù)器端之間信息實時交互 d).可以加密,數(shù)據(jù)安全性強

B).劣勢:

a).需對傳輸?shù)臄?shù)據(jù)進行解析，轉(zhuǎn)化成應(yīng)用級的數(shù)據(jù) b).相對于HTTP協(xié)議傳輸，增加了開發(fā)量 c).對開發(fā)人員的開發(fā)水平要求高

4).基于Socket傳輸?shù)奶攸c其適用于對傳輸速度，安全性，實時交互，費用等要求高的應(yīng)用中，如網(wǎng)絡(luò)游戲，手機應(yīng)用，銀行內(nèi)部交互等

**

四、拓展：

**

http://geosmart.github.io/2017/09/17/Web開發(fā)常用協(xié)議/

https://www.cnblogs.com/fzz9/p/8964513.htm

Socket
https://blog.csdn.net/alpha_love/article/details/62043077

總結(jié)

以上是生活随笔為你收集整理的网络编程——常用协议解析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。