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

http://yzkb.51969.com/

1 引言

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

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

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

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

2 IP協(xié)議

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

2.1 IP協(xié)議的特點

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

2.2 為什么要使用IPv6？

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

IPv6地址表示方法：

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

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

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

3 TCP/UDP

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

3.1 TCP

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

3.1.1 TCP報文格式

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

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

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

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

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

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

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

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

3.2 UDP

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

3.2.1 UDP報文格式

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

3.2.2 UDP特性

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

3 HTTP/HTTPS

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

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

3.1.1 HTTP特點

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

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

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

3.1.2 HTTP請求之request

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

3.1.3 Http響應之response

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

3.2 HTTPS

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

3.2.1 HTTPS的作用

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

3.2.2 HTTPS的劣勢

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

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

出于安全考慮，瀏覽器不會在本地保存HTTPS緩存。實際上，只要在HTTP頭中使用特定命令，HTTPS是可以緩存的。Firefox默認只在內(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)建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，比HTTP協(xié)議安全。

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

4 FTP

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

4.1 FTP協(xié)議的原理

????????FTP協(xié)議實際上是工作在TCP/IP協(xié)議族的應用層，其傳輸層協(xié)議是TCP協(xié)議?？梢灾?，他的文件傳輸是可靠的。

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

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

4.2 FTP工作詳解

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

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

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

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

5 SMTP

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

5.1 工作機制

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

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

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

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

返回面試寶典

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

http://yzkb.51969.com/

相關(guān)鏈接