柚子快報(bào)激活碼778899分享：網(wǎng)絡(luò)協(xié)議梳理

http://yzkb.51969.com/

1 引言

????????在計(jì)算機(jī)網(wǎng)絡(luò)中要做到有條不紊地交換數(shù)據(jù)，就必須遵守一些事先約定好的規(guī)則。這些規(guī)則明確規(guī)定了所交換的數(shù)據(jù)的格式以及有關(guān)的同步問題。這里所說的同步不是狹義的（即同頻或同頻同相）而是廣義的，即在一定的條件下應(yīng)當(dāng)發(fā)生什么事情（例如，應(yīng)當(dāng)發(fā)送一個應(yīng)答信息），因而同步含有時(shí)序的意思。這些為進(jìn)行網(wǎng)絡(luò)中的數(shù)據(jù)交換而建立的規(guī)則、標(biāo)準(zhǔn)或約定稱為網(wǎng)絡(luò)協(xié)議（network protocol）。網(wǎng)絡(luò)協(xié)議也可簡稱為協(xié)議。更進(jìn)一步的講，網(wǎng)絡(luò)協(xié)議主要由以下三個要素組成：

語法，即數(shù)據(jù)與控制信息的結(jié)構(gòu)或格式；語義，即需要發(fā)出何種控制信息，完成何種動作以及做出何種響應(yīng)；同步，即事件實(shí)現(xiàn)順序的詳細(xì)說明。

????????由此可見，網(wǎng)絡(luò)協(xié)議是計(jì)算機(jī)網(wǎng)絡(luò)不可缺少的部分。實(shí)際上，只要我們想讓連接在網(wǎng)絡(luò)上的另一臺計(jì)算機(jī)做點(diǎn)兒什么事情（例如，從網(wǎng)絡(luò)上的某臺主機(jī)下載文件），我們都需要有協(xié)議。 ????????協(xié)議通常有兩種不同的形式。一種是使用便于人來閱讀和理解的文字描述，另一種是使用讓計(jì)算機(jī)能夠理解的程序代碼。這兩種不同形式的協(xié)議都必須能夠?qū)W(wǎng)絡(luò)上的信息交換過程做出精確的解釋。

????????常見的計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)主要有：OSI的七層協(xié)議、TCP\IP的四層協(xié)議和五層協(xié)議，本文主要講述應(yīng)用最為廣泛的TCP/IP協(xié)議。

2 IP協(xié)議

????????IP 協(xié)議是把上層數(shù)據(jù)報(bào)封裝成 IP 數(shù)據(jù)報(bào)后進(jìn)行傳輸，如果 IP 數(shù)據(jù)報(bào)太大，還要對數(shù)據(jù)報(bào)進(jìn)行分片后再傳輸，到了目的地址處再進(jìn)行組裝還原，以適應(yīng)不同物理網(wǎng)絡(luò)對一次所能傳輸數(shù)據(jù)大小的要求。

2.1 IP協(xié)議的特點(diǎn)

IP協(xié)議是一種無連接、不可靠的分組傳送服務(wù)的協(xié)議；IP協(xié)議是點(diǎn)-點(diǎn)線路的網(wǎng)絡(luò)層通信協(xié)議。IP協(xié)議是針對原主機(jī)-路由器、路由器-路由器、路由器-目的主機(jī)之間的數(shù)據(jù)傳輸?shù)狞c(diǎn)-點(diǎn)線路網(wǎng)絡(luò)層通信協(xié)議；IP協(xié)議屏蔽了網(wǎng)絡(luò)在數(shù)據(jù)鏈路層、物理層協(xié)議與實(shí)際技術(shù)上的差異。通過IP協(xié)議，網(wǎng)絡(luò)層向傳輸層提供的是統(tǒng)一的IP分組，傳輸層不需要考慮互聯(lián)網(wǎng)在數(shù)據(jù)鏈路層、物理層協(xié)議與實(shí)現(xiàn)技術(shù)上的差異，IP協(xié)議使得異構(gòu)網(wǎng)絡(luò)的互聯(lián)變得容易了

2.2 為什么要使用IPv6？

????????目前，主流IP是基于IPv4的，但I(xiàn)PV4網(wǎng)絡(luò)難以實(shí)現(xiàn)網(wǎng)絡(luò)實(shí)名制，一個重要原因就是因?yàn)镮P資源的共用，因?yàn)镮P資源不夠（IPV4為32位），所以不同的人在不同的時(shí)間段共用一個IP，IP和上網(wǎng)用戶無法實(shí)現(xiàn)一一對應(yīng)。而IPv6（128位，足夠長）的普及將改變現(xiàn)狀，因?yàn)镮Pv6一個重要的應(yīng)用將是實(shí)現(xiàn)網(wǎng)絡(luò)實(shí)名制下的互聯(lián)網(wǎng)身份證/VIeID。

IPv6地址表示方法：

冒分十六進(jìn)制表示法；0位壓縮表示法；內(nèi)嵌IPv4地址表示法。

2.3 IP數(shù)據(jù)包的格式

????????數(shù)據(jù)報(bào)格式如下：首部的長度是以32位（4個字節(jié)）為單位，長度可以是20-60字節(jié)，這跟首部長度字段有關(guān)。 ????????一個IP數(shù)據(jù)報(bào)由首部和數(shù)據(jù)兩部分組成。首部的前一部分是固定長度，共20字節(jié)，是所有IP數(shù)據(jù)報(bào)必須具有的。在首部的固定部分的后面是一些可選字段，其長度是可變的。

3 TCP/UDP

????????在TCP/IP體系結(jié)構(gòu)的傳輸層兩個重要協(xié)議是TCP、UDP。

3.1 TCP

????????TCP(Transmission Control Protocol 傳輸控制協(xié)議)是一種面向連接的、可靠的， 基于IP的傳輸層協(xié)議。TCP在IP報(bào)文的協(xié)議號是6。TCP是一個超級麻煩的協(xié)議，而它又是互聯(lián)網(wǎng)的基礎(chǔ)。

3.1.1 TCP報(bào)文格式

????????如上圖所示，TCP數(shù)據(jù)格式是由若干具有特殊含義字段組成的。

Source Port和Destination Port：分別占用16位，表示源端口號和目的端口號;用于區(qū)別主機(jī)中的不同進(jìn)程， 而IP地址是用來區(qū)分不同的主機(jī)的，源端口號和目的端口號配合上IP首部中的源IP地址和目的IP地址就能唯一 的確定一個TCP連接； Sequence Number：用來標(biāo)識從TCP發(fā)端向TCP收端發(fā)送的數(shù)據(jù)字節(jié)流，它表示在這個報(bào)文段中的的第一個數(shù)據(jù) 字節(jié)在數(shù)據(jù)流中的序號;主要用來解決網(wǎng)絡(luò)報(bào)亂序的問題； Acknowledgment Number：32位確認(rèn)序列號包含發(fā)送確認(rèn)的一端所期望收到的下一個序號，因此，確認(rèn)序號應(yīng) 當(dāng)是上次已成功收到數(shù)據(jù)字節(jié)序號加1。不過，只有當(dāng)標(biāo)志位中的ACK標(biāo)志(下面介紹)為1時(shí)該確認(rèn)序列號的字 段才有效。主要用來解決不丟包的問題； Offset：給出首部中32 bit字的數(shù)目，需要這個值是因?yàn)槿芜x字段的長度是可變的。這個字段占4bit(最多能 表示15個32bit的的字，即4*15=60個字節(jié)的首部長度)，因此TCP最多有60字節(jié)的首部。然而，沒有任選字段， 正常的長度是20字節(jié)； TCP Flags:TCP首部中有6個標(biāo)志比特，它們中的多個可同時(shí)被設(shè)置為1，主要是用于操控TCP的狀態(tài)機(jī)的，依次 為URG，ACK，PSH，RST，SYN，F(xiàn)IN。 URG：此標(biāo)志表示TCP包的緊急指針域(后面馬上就要說到)有效，用來保證TCP連接不被中斷，并且督促 中間層設(shè)備要盡快處理這些數(shù)據(jù)； ACK：此標(biāo)志表示應(yīng)答域有效，就是說前面所說的TCP應(yīng)答號將會包含在TCP數(shù)據(jù)包中;有兩個取值：0和1， 為1的時(shí)候表示應(yīng)答域有效，反之為0； PSH：這個標(biāo)志位表示Push操作。所謂Push操作就是指在數(shù)據(jù)包到達(dá)接收端以后，立即傳送給應(yīng)用程序， 而不是在緩沖區(qū)中排隊(duì)； RST：這個標(biāo)志表示連接復(fù)位請求。用來復(fù)位那些產(chǎn)生錯誤的連接，也被用來拒絕錯誤和非法的數(shù)據(jù)包； SYN：表示同步序號，用來建立連接。SYN標(biāo)志位和ACK標(biāo)志位搭配使用，當(dāng)連接請求的時(shí)候，SYN=1， ACK=0；連接被響應(yīng)的時(shí)候，SYN=1，ACK=1；這個標(biāo)志的數(shù)據(jù)包經(jīng)常被用來進(jìn)行端口掃描。掃描者發(fā)送 一個只有SYN的數(shù)據(jù)包，如果對方主機(jī)響應(yīng)了一個數(shù)據(jù)包回來 ，就表明這臺主機(jī)存在這個端口;但是由于這 種掃描方式只是進(jìn)行TCP三次握手的第一次握手，因此這種掃描的成功表示被掃描的機(jī)器不很安全，一臺安全 的主機(jī)將會強(qiáng)制要求一個連接嚴(yán)格的進(jìn)行TCP的三次握手； Window：窗口大小，也就是有名的滑動窗口，用來進(jìn)行流量控制。這是一個復(fù)雜的問題，本文不再論述。

3.1.2 TCP協(xié)議的三次握手

????????TCP是面向連接的，無論哪一方向另一方發(fā)送數(shù)據(jù)之前，都必須先在雙方之間建立一條連接。在TCP/IP協(xié)議中，TCP 協(xié)議提供可靠的連接服務(wù)，連接是通過三次握手進(jìn)行初始化的。三次握手的目的是同步連接雙方的序列號和確認(rèn)號并交換 TCP窗口大小信息。如下圖TCP的通信過程所示： ????????三次握手具體過程（狀態(tài)）如下（其實(shí)可以類比打電話的過程：甲打電話，并等待接聽→乙收到來電顯示，“并表示可以接聽”→“甲收到乙可以接聽的信息”，甲接聽電話。注：引號部分是打電話過程中沒有的，但在TCP三次握手中存在）：

????????第一次握手：建立連接?？蛻舳税l(fā)送連接請求報(bào)文段，將SYN位置為1，Sequence Number為x;然后，客戶端進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器的確認(rèn)。（客戶的建立連接并等待確認(rèn)）

????????第二次握手：服務(wù)器收到SYN報(bào)文段。服務(wù)器收到客戶端的SYN報(bào)文段，需要對這個SYN報(bào)文段進(jìn)行確認(rèn)，設(shè)置Acknowledgment Number為x+1(Sequence Number+1);同時(shí)，自己自己還要發(fā)送SYN請求信息，將SYN位置為1，Sequence Number為y;服務(wù)器端將上述所有信息放到一個報(bào)文段(即SYN+ACK報(bào)文段)中，一并發(fā)送給客戶端，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)。（服務(wù)器端發(fā)送相關(guān)報(bào)文段信息并等待連接）

????????第三次握手：客戶端收到服務(wù)器的SYN+ACK報(bào)文段。然后將Acknowledgment Number設(shè)置為y+1，向服務(wù)器發(fā)送ACK報(bào)文段，這個報(bào)文段發(fā)送完畢以后，客戶端和服務(wù)器端都進(jìn)入ESTABLISHED狀態(tài)，完成TCP三次握手。（客戶的接收到服務(wù)端信息并實(shí)現(xiàn)連接）

????????然后，客戶端和服務(wù)端就能實(shí)現(xiàn)正常的數(shù)據(jù)傳輸啦！

3.2 UDP

????????UDP 是User Datagram Protocol的簡稱， 中文名是用戶數(shù)據(jù)報(bào)協(xié)議，是OSI（Open System Interconnection，開放式系統(tǒng)互聯(lián)） 參考模型中一種無連接的傳輸層協(xié)議，提供面向事務(wù)的簡單不可靠信息傳送服務(wù)，IETF RFC 768是UDP的正式規(guī)范。UDP在IP報(bào)文的協(xié)議號是17。

3.2.1 UDP報(bào)文格式

與TCP協(xié)議不同，UDP協(xié)議是非面向連接的不可靠協(xié)議，因此沒有了SYN等處理兩端等待或連接的報(bào)文段，相比之下，UDP的報(bào)文格式更為簡單，主要由報(bào)文頭（由均16位的源端口號、目的端口號、UDP長度和UDP校驗(yàn)和組成）和具體傳輸數(shù)據(jù)組成。如圖所示： UDP長度：UDP報(bào)文的整個大小，最小為8個字節(jié)（16*4位）（僅為首部）。 UDP檢驗(yàn)和：在進(jìn)行檢驗(yàn)和計(jì)算時(shí)，會添加一個偽首部一起進(jìn)行運(yùn)算。偽首部（占用12個字節(jié)）為：4個字節(jié)的源IP地址、4個字節(jié)的目的IP地址、1個字節(jié)的0、一個字節(jié)的數(shù)字17、以及占用2個字節(jié)UDP長度。這個偽首部不是報(bào)文的真正首部，只是引入為了計(jì)算校驗(yàn)和。相對于IP協(xié)議的只計(jì)算首部，UDP檢驗(yàn)和會把首部和數(shù)據(jù)一起進(jìn)行校驗(yàn)。接收端進(jìn)行的校驗(yàn)和與UDP報(bào)文中的校驗(yàn)和相與，如果無差錯應(yīng)該全為1。如果有誤，則將報(bào)文丟棄或者發(fā)給應(yīng)用層、并附上差錯警告。

3.2.2 UDP特性

UDP是一個無連接協(xié)議，傳輸數(shù)據(jù)之前源端和終端不建立連接，當(dāng) UDP想傳送時(shí)就簡單地去抓取來自應(yīng)用程序的數(shù)據(jù)，并盡可能快地把它扔到網(wǎng)絡(luò)上。在發(fā)送端，UDP傳送數(shù)據(jù)的速度僅僅是受應(yīng)用程序生成數(shù)據(jù)的速度、計(jì)算機(jī)的能力和傳輸帶寬的限制；在接收端，UDP把每個消息段放在隊(duì)列中，應(yīng)用程序每次從隊(duì)列中讀一個消息段。由于傳輸數(shù)據(jù)不建立連接，因此也就不需要維護(hù)連接狀態(tài)，包括收發(fā)狀態(tài)等，因此一臺服務(wù)機(jī)可同時(shí)向多個客戶機(jī)傳輸相同的消息。UDP信息包的標(biāo)題很短，只有8個字節(jié)，相對于TCP的20個字節(jié)信息包的額外開銷很小。吞吐量不受擁擠控制算法的調(diào)節(jié)，只受應(yīng)用軟件生成數(shù)據(jù)的速率、傳輸帶寬、源端和終端主機(jī)性能的限制。UDP使用盡最大努力交付，即不保證可靠交付，因此主機(jī)不需要維持復(fù)雜的鏈接狀態(tài)表（這里面有許多參數(shù)）UDP是面向報(bào)文的。發(fā)送方的UDP對應(yīng)用程序交下來的報(bào)文，在添加首部后就向下交付給IP層。既不拆分，也不合并，而是保留這些報(bào)文的邊界，因此，應(yīng)用程序需要選擇合適的報(bào)文大小。 雖然UDP是一個不可靠的協(xié)議，但它是分發(fā)信息的一個理想?yún)f(xié)議。

3.3 TCP與UDP的區(qū)別

????????TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)協(xié)議屬于傳輸層協(xié)議，它們之間的區(qū)別包括：

TCP是面向連接的，UDP是無連接的；TCP是可靠的，UDP是不可靠的；TCP只支持點(diǎn)對點(diǎn)通信，UDP支持一對一、一對多、多對一、多對多的通信模式；TCP是面向字節(jié)流的，UDP是面向報(bào)文的；TCP有擁塞控制機(jī)制;UDP沒有擁塞控制，適合媒體通信；TCP首部開銷(20個字節(jié))比UDP的首部開銷(8個字節(jié))要大；

3 HTTP/HTTPS

????????HTTP/HTTPS是運(yùn)行在TCP協(xié)議上的協(xié)議。HTTP（Hypertext Transfer Protocol，超文本傳輸協(xié)議）主要用于普通瀏覽，HTTPS（HTTP over SSL，安全超文本傳輸協(xié)議）是HTTP協(xié)議的安全版本。

3.1 HTTP

????????超文本傳輸協(xié)議（HTTP，HyperText Transfer Protocol)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的萬維網(wǎng)WWW（World Wide Web）文件都必須遵守這個標(biāo)準(zhǔn)。設(shè)計(jì)HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁面的方法。1960年美國人Ted Nelson構(gòu)思了一種通過計(jì)算機(jī)處理文本信息的方法，并稱之為超文本（hypertext）,這成為了HTTP超文本傳輸協(xié)議標(biāo)準(zhǔn)架構(gòu)的發(fā)展根基。 ????????HTTP是一個基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)（HTML 文件, 圖片文件, 查詢結(jié)果等）。HTTP是一個屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，由于其簡捷、快速的方式，適用于分布式超媒體信息系統(tǒng)。它于1990年提出，經(jīng)過幾年的使用與發(fā)展，得到不斷地完善和擴(kuò)展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規(guī)范化工作正在進(jìn)行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經(jīng)提出。

????????HTTP協(xié)議工作于客戶端-服務(wù)端架構(gòu)為上。瀏覽器作為HTTP客戶端通過URL向HTTP服務(wù)端即WEB服務(wù)器發(fā)送所有請求。Web服務(wù)器根據(jù)接收到的請求后，向客戶端發(fā)送響應(yīng)信息。

3.1.1 HTTP特點(diǎn)

????????HTTP是一個客戶端和服務(wù)器端請求和應(yīng)答的標(biāo)準(zhǔn)，通常，由HTTP客戶端發(fā)起一個請求，建立一個到服務(wù)器指定端口（默認(rèn)是80端口）的TCP連接。HTTP服務(wù)器則在那個端口監(jiān)聽客戶端發(fā)送過來的請求。一旦收到請求，服務(wù)器（向客戶端）發(fā)回一個狀態(tài)行。HTTP使用TCP而不是UDP的原因在于（打開）一個網(wǎng)頁必須傳送很多數(shù)據(jù)，而TCP協(xié)議提供傳輸控制，按順序組織數(shù)據(jù)，和錯誤糾正。

????????通過HTTP或者HTTPS協(xié)議（HTTP協(xié)議+SSL協(xié)議）請求的資源由統(tǒng)一資源標(biāo)示符（Uniform Resource Identifiers）來標(biāo)識。HTTP有以下特點(diǎn)：

簡單快速：客戶向服務(wù)器請求服務(wù)時(shí)，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。無連接：無連接的含義是限制每次連接只處理一個請求。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間。無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。支持B/S及C/S模式。

3.1.2 HTTP請求之request

????????客戶端通過HTTP協(xié)議進(jìn)行請求時(shí)遵循一定的格式，請看下面的請求報(bào)文格式（由請求行、請求頭、空行、請求體組成）： ????????而各部分組成如下所示：

3.1.3 Http響應(yīng)之response

????????在客戶端發(fā)送請求后服務(wù)端進(jìn)行響應(yīng)，將信息發(fā)送給客戶端，以實(shí)現(xiàn)功能服務(wù)，報(bào)文格式如下（包含狀態(tài)行、響應(yīng)頭、空行、消息體）： ????????響應(yīng)組成此處也不再贅述，值得注意的是狀態(tài)碼，它以清晰明確的數(shù)字告訴客戶端本次請求的處理結(jié)果。 常見的狀態(tài)碼有：

3.2 HTTPS

????????HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。

3.2.1 HTTPS的作用

內(nèi)容加密建立一個信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩?；身份認(rèn)證確認(rèn)網(wǎng)站的真實(shí)性數(shù)據(jù)完整性防止內(nèi)容被第三方冒充或者篡改

3.2.2 HTTPS的劣勢

對數(shù)據(jù)進(jìn)行加解密決定了它比http慢

需要進(jìn)行非對稱的加解密，且需要三次握手。首次連接比較慢點(diǎn)，當(dāng)然現(xiàn)在也有很多的優(yōu)化。

出于安全考慮，瀏覽器不會在本地保存HTTPS緩存。實(shí)際上，只要在HTTP頭中使用特定命令，HTTPS是可以緩存的。Firefox默認(rèn)只在內(nèi)存中緩存HTTPS。但是，只要頭命令中有Cache-Control: Public，緩存就會被寫到硬盤上。 IE只要http頭允許就可以緩存https內(nèi)容，緩存策略與是否使用HTTPS協(xié)議無關(guān)。

3.2.3 HTTPS和HTTP的區(qū)別

HTTPS協(xié)議需要到CA申請證書。HTTP是超文本傳輸協(xié)議，信息是明文傳輸；HTTPS則是具有安全性的ssl加密傳輸協(xié)議。HTTP和HTTPS使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。HTTP的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比HTTP協(xié)議安全。

下面就是HTTPS的整個架構(gòu)，現(xiàn)在的HTTPS基本都使用TLS了，會更加安全。

4 FTP

????????FTP 是File Transfer Protocol（文件傳輸協(xié)議）。用于ftp客戶端和ftp服務(wù)器之間進(jìn)行文本、文件傳輸?shù)膮f(xié)議。與http的短連接不同，F(xiàn)TP協(xié)議是一種基于socket的長連接。

4.1 FTP協(xié)議的原理

????????FTP協(xié)議實(shí)際上是工作在TCP/IP協(xié)議族的應(yīng)用層，其傳輸層協(xié)議是TCP協(xié)議?？梢灾溃奈募鬏斒强煽康?。

FTP的工作流程大致分為四步：

啟動FTP。ftp的客戶端啟動一個socket連接到服務(wù)器。建立控制連接。客戶端和服務(wù)器通過三次握手過程（21端口），建立連接，用于傳輸ftp協(xié)議的命令。建立數(shù)據(jù)連接?？蛻舳撕头?wù)器建立數(shù)據(jù)連接（分為主動模式和被動模式），用戶文件的傳輸。關(guān)閉FTP。ftp客戶端清空數(shù)據(jù)流，并且關(guān)閉Socket。

4.2 FTP工作詳解

1、FTP協(xié)議的工作流程中為什么有控制連接和數(shù)據(jù)連接？

FTP協(xié)議的控制鏈接是用于客戶端向服務(wù)器發(fā)送ftp的命令用的，只要不想關(guān)閉FTP客戶端，就會一直保持該連接，用戶之后的命令交互。而數(shù)據(jù)連接，則是區(qū)別于控制鏈接之外的，用戶傳輸文件用的socket連接，當(dāng)傳輸文件結(jié)束時(shí)，就關(guān)閉連接。

2、數(shù)據(jù)連接的主動模式和被動模式？

????????FTP的數(shù)據(jù)連接過程中的主動模式和被動模式，是相對于FTP服務(wù)器來說都。 ????????主動模式：FTP客戶端在客戶端建立一個socket，端口為B,并通過FTP控制連接的通道發(fā)送PORT命令，告訴FTP服務(wù)器：“客戶端已經(jīng)對B端口進(jìn)行了監(jiān)聽”；然后FTP服務(wù)器主動與FTP客戶端的B端口建立連接。 ????????被動模式：FTP客戶端通過FTP的控制連接的通道，發(fā)送PASV命令，告訴FTP服務(wù)器：“我要建立數(shù)據(jù)連接”；然后FTP服務(wù)器會隨機(jī)啟動一個端口X的監(jiān)聽，并在返回信息中告訴FTP客戶端：“可以與X端口建立連接”；最后，F(xiàn)TP客戶端主動與FTP服務(wù)器的X端口建立連接。

5 SMTP

????????SMTP稱為簡單郵件傳輸協(xié)議（Simple Mail Transfer Protocal），目標(biāo)是向用戶提供高效、可靠的郵件傳輸。它的一個重要特點(diǎn)是它能夠在傳送中接力傳送郵件，即郵件可以通過不同網(wǎng)絡(luò)上的主機(jī)接力式傳送。通常它工作在兩種情況下：一是郵件從客戶機(jī)傳輸?shù)椒?wù)器；二是從某一個服務(wù)器傳輸?shù)搅硪粋€服務(wù)器。SMTP是一個請求/響應(yīng)協(xié)議，它監(jiān)聽25號端口，用于接收用戶的Mail請求，并與遠(yuǎn)端Mail服務(wù)器建立SMTP連接。

5.1 工作機(jī)制

????????SMTP通常有兩種工作模式。發(fā)送SMTP和接收SMTP。具體工作方式為：發(fā)送SMTP在接收到用戶的郵件請求后，判斷此郵件是否為本地郵件，若是直接投送到用戶的郵箱，否則向DNS查詢遠(yuǎn)端郵件服務(wù)器的MX記錄，并建立與遠(yuǎn)端接收SMTP之間的一個雙向傳送通道，此后SMTP命令由發(fā)送SMTP發(fā)出，由接收SMTP接收，而應(yīng)答則反方向傳送。一旦傳送通道建立，SMTP發(fā)送者發(fā)送MAIL命令指明郵件發(fā)送者。如果SMTP接收者可以接收郵件則返回OK應(yīng)答。SMTP發(fā)送者再發(fā)出RCPT命令確認(rèn)郵件是否接收到。如果SMTP接收者接收，則返回OK應(yīng)答；如果不能接收到，則發(fā)出拒絕接收應(yīng)答（但不中止整個郵件操作），雙方將如此反復(fù)多次。當(dāng)接收者收到全部郵件后會接收到特別的序列，如果接收者成功處理了郵件，則返回OK應(yīng)答。

5.2 連接和發(fā)送過程

建立TCP連接客戶端發(fā)送HELO命令以標(biāo)識發(fā)件人自己的身份，然后客戶端發(fā)送MAIL命令； 服務(wù)器端正希望以O(shè)K作為響應(yīng)，表明準(zhǔn)備接收客戶端發(fā)送RCPT命令，以標(biāo)識該電子郵件的計(jì)劃接收人，可以有多個RCPT行；服務(wù)器端則表示是否愿意為收件人接收郵件協(xié)商結(jié)束，發(fā)送郵件，用命令DATA發(fā)送以.表示結(jié)束輸入內(nèi)容一起發(fā)送出去結(jié)束此次發(fā)送，用QUIT命令退出

最后附上常見的網(wǎng)絡(luò)協(xié)議圖解

返回面試寶典

柚子快報(bào)激活碼778899分享：網(wǎng)絡(luò)協(xié)議梳理

http://yzkb.51969.com/

相關(guān)鏈接