無論做前端開發(fā)還是后端開發(fā)，網(wǎng)絡知識是必備的知識。這部分知識是基礎中的基礎，是我們必須掌握的內(nèi)容。網(wǎng)絡相關的問題也是在面試過程中經(jīng)常被問到的內(nèi)容。本文主要梳理了一下網(wǎng)絡相關的主要知識點及面試中經(jīng)常被問到的內(nèi)容，希望對大家有所幫助。
OSI有哪幾層，會畫出來，知道主要幾層的各自作用
OSI（Open System Interconnect），即開放式系統(tǒng)互聯(lián)，是ISO（國際標準化組織）組織在1985年研究的網(wǎng)絡互連模型。其一共有7層：
1. 應用層（數(shù)據(jù)）：確定進程之間通信的性質(zhì)以滿足用戶需要以及提供網(wǎng)絡與用戶應用
2. 表示層（數(shù)據(jù)）：主要解決擁護信息的語法表示問題，如加密解密
3. 會話層（數(shù)據(jù)）：提供包括訪問驗證和會話管理在內(nèi)的建立和維護應用之間通信的機制，如服務器驗證用戶登錄便是由會話層完成的
4. 運輸層（段）：實現(xiàn)網(wǎng)絡不同主機上用戶進程之間的數(shù)據(jù)通信，可靠
與不可靠的傳輸，傳輸層的錯誤檢測，流量控制等
5. 網(wǎng)絡層（包）：提供邏輯地址（IP）、選路，數(shù)據(jù)從源端到目的端的
傳輸
6. 數(shù)據(jù)鏈路層（幀）：將上層數(shù)據(jù)封裝成幀，用MAC地址訪問媒介，錯誤檢測與修正
7. 物理層（比特流）：設備之間比特流的傳輸，物理接口，電氣特性等*
TCP/IP有哪幾層，會畫出來，知道所有層數(shù)的作用，會列舉各層主要的協(xié)議名稱
TCP/IP分層模型（TCP/IP Layening Model）被稱作因特網(wǎng)分層模型(Internet Layering Model)、因特網(wǎng)參考模型(Internet Reference Model)。
1. 應用層（TELNET、FTP、SMTP）
2. 運輸層（TCP、UDP）
3. 網(wǎng)際層（IP、ICMP）
4. 網(wǎng)絡接口層（PPP）*
各個層使用的是哪個數(shù)據(jù)交換設備。（交換機、路由器、網(wǎng)關）
在廣域網(wǎng)場景下，整個網(wǎng)絡傳輸需要經(jīng)過很多設備，包括網(wǎng)關、交換機、路由器等等，
- 網(wǎng)關：應用層、傳輸層（網(wǎng)關在傳輸層上以實現(xiàn)網(wǎng)絡互連，是最復雜的網(wǎng)絡互連設備，僅用于兩個高層協(xié)議不同的網(wǎng)絡互連。網(wǎng)關的結構也和路由器類似，不同的是互連層。網(wǎng)關既可以用于廣域網(wǎng)互連，也可以用于局域網(wǎng)互連）
- 路由器：網(wǎng)絡層（路由選擇、存儲轉(zhuǎn)發(fā)）
- 交換機：數(shù)據(jù)鏈路層、網(wǎng)絡層（識別數(shù)據(jù)包中的MAC地址信息，根據(jù)MAC地址進行轉(zhuǎn)發(fā)，并將這些MAC地址與對應的端口記錄在自己內(nèi)部的一個地址表中）
- 網(wǎng)橋：數(shù)據(jù)鏈路層（將兩個LAN連起來，根據(jù)MAC地址來轉(zhuǎn)發(fā)幀）
- 集線器（Hub）：物理層（純硬件設備，主要用來連接計算機等網(wǎng)絡終端）
- 中繼器：物理層（在比特級別對網(wǎng)絡信號進行再生和重定時，從而使得它們能夠在網(wǎng)絡上傳輸更長的距離）
TCP協(xié)議是如何定義的，它的數(shù)據(jù)格式是什么樣子的？
TCP是基于傳輸層的協(xié)議，協(xié)議文件可從RFC793得到，使用廣泛，面向連接的可靠協(xié)議。它能把報文分解為數(shù)段，在目的站再重新裝配這些段，支持重新發(fā)送未被收到的段，提供兩臺設備間的全雙工連接，允許它們高效地交換大量數(shù)據(jù)。TCP使用滑動窗口協(xié)議來高效使用網(wǎng)絡。由于TCP很少干預底層投遞系統(tǒng)的工作，它適應各種投遞系統(tǒng)，且提供流量控制，能使各種不同速率的系統(tǒng)進行通信。報文段是TCP所使用的基本傳輸單元，用于傳輸數(shù)據(jù)或控制信息。如下是TCP協(xié)議的報文格式：
IP報文的格式，格式的各個字段的含義要理解
IP是Internet最基本的協(xié)議。IP是面向報文的協(xié)議，它獨立處理每個報文包，每個報文包必須含有完整的尋址信息。IP報文包的格式如圖所示：
關于TCP/IP的內(nèi)容，請參考本號之前的文章《從socket到TCP協(xié)議，透徹理解網(wǎng)絡編程》。
ICMP協(xié)議的主要功能
用于在IP主機、路由器之間傳遞控制消息
IP地址的分類，如何劃分的，及會計算各類地址支持的主機數(shù)
IP地址的類型共有4種（如圖3所示）：A類用于處理超大型網(wǎng)絡，最多16387064個主機（1～126）；B類網(wǎng)絡最多可有64516個主機（網(wǎng)絡地址的第一段為128～191）；C類用于小型網(wǎng)絡，最多可有254個主機（網(wǎng)絡地址的第一段為192～223）；D類用于多點播送，用于多目的信息的傳輸。全零（“0.0.0.0”）地址對應于當前主機，全1地址（“255.255.255.255”）是當前子網(wǎng)的廣播地址。
1. A類地址：首位為0，1.0.0.1~~126.255.255.254；主機號24位
2. B類地址：首位為10，128.0.0.1~~191.255.255.254；主機號16位
3. C類地址：首位為110，192.0.0.1~~223.255.255.254；主機號8位
4. D類地址（多播地址，也叫做組播地址）：首位為1110，224.0.0.1~~239.255.255.254
5. E類地址：此類地址是保留地址，首位為11110，240.0.0.1~~254.255.255.254
劃分子網(wǎng)、構造超網(wǎng)
- 劃分子網(wǎng)（變長子網(wǎng)掩碼VLSM）：劃分子網(wǎng)的方法是從網(wǎng)絡的主機號借用若干位作為子網(wǎng)號subnet-id，與此同時主機號也減少相應位數(shù)（總位數(shù)32位不變）。由此兩級IP地址可變?yōu)槿塈P地址： IP地址 ::= {<網(wǎng)絡號>,<子網(wǎng)號>,<主機號>}，劃分子網(wǎng)只是把IP地址的主機號這部分進行再劃分，并不改變IP地址原來的網(wǎng)絡號
- 構造超網(wǎng)（無分類編址CIDR）：CIDR消除了傳統(tǒng)的A類、B類和C類地址以及劃分子網(wǎng)的概念，把32位的IP地址劃分為兩個部分。如：128.14.35.7/20是某個CIDR地址塊中的一個地址，其前20位是網(wǎng)絡前綴（用下劃線表示的部分），后面的12位為主機號*
DNS的概念，用途，DNS查詢的實現(xiàn)算法
- 概念
域名解析，www.xxx.com轉(zhuǎn)換成ip，能夠使用戶更方便的訪問互聯(lián)網(wǎng)，而不用去記住能夠被機器直接讀取的ip數(shù)串
DNS協(xié)議運行在UDP協(xié)議之上，使用端口號53 - 主機解析域名的順序
- 瀏覽器緩存
- 找本機的hosts文件
- 路由緩存
- 找DNS服務器(本地域名、頂級域名、根域名)
- 迭代查詢、遞歸查詢*
常見熟知端口
TCP與UDP的概念相互的區(qū)別及優(yōu)劣
1. TCP面向連接，UDP面向無鏈接
2. TCP面向報文，UDP面向字節(jié)流
3. TCP提供可靠傳輸服務（數(shù)據(jù)順序、正確性），UDP傳輸不可靠
4. TCP協(xié)議傳輸速度慢，UDP協(xié)議傳輸速度快
5. TCP協(xié)議對系統(tǒng)資源要求多（頭部開銷大），UDP協(xié)議要求少*
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é)議進行數(shù)據(jù)傳輸，如圖是兩者之間的關系。
TCP報文的格式，字段的意義
TCP通過哪些措施，保證傳輸可靠
1. 流量控制
2. 讓發(fā)送方的發(fā)送速率不要太快，要讓接收方來得及接收
3. 窗口大小是一個可以改變的值，它由接收端主機控制，附加在 TCP 首部的“窗口大小”字段中
4. 擁塞控制
5. 防止過多的數(shù)據(jù)注入到網(wǎng)絡中，這樣可以使網(wǎng)絡中的路由器或鏈路不致過載
6. 擁塞控制方法：慢開始、擁塞避免、快重傳和快恢復* ### 三次握手，四次斷開過程
請求各個狀態(tài)的意義如下
1. LISTEN - 偵聽來自遠方TCP端口的連接請求；
2. SYN-SENT -在發(fā)送連接請求后等待匹配的連接請求；
3. SYN-RECEIVED - 在收到和發(fā)送一個連接請求后等待對連接請求的確認；
4. ESTABLISHED- 代表一個打開的連接，數(shù)據(jù)可以傳送給用戶；
5. FIN-WAIT-1 - 等待遠程TCP的連接中斷請求，或先前的連接中斷請求的確認；
6. FIN-WAIT-2 - 從遠程TCP等待連接中斷請求；
7. CLOSE-WAIT - 等待從本地用戶發(fā)來的連接中斷請求；
8. CLOSING -等待遠程TCP對連接中斷的確認；
9. LAST-ACK - 等待原來發(fā)向遠程TCP的連接中斷請求的確認；
10. TIME-WAIT -等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認；
11. CLOSED - 沒有任何連接狀態(tài)；*
TCP 的擁塞控制是怎樣的
擁塞算法：
慢啟動（Slow Start）發(fā)送方維護擁塞窗口變量cwnd，先用小數(shù)據(jù)試探網(wǎng)絡擁塞，沒問題后來斷加倍
擁塞避免（Congestion voidance）：擁塞窗口緩慢增長，即每經(jīng)過一個往返時間RTT就把發(fā)送方的擁塞窗口cwnd加1
重傳機制
快速重傳（Fast Retransmit）：快重傳要求接收方收到失序報文段后立即發(fā)出重復確認（為的是使發(fā)送方及早知道有報文段沒有到達對方）而不要等到自己發(fā)送數(shù)據(jù)時捎帶確認。快重傳算法規(guī)定，發(fā)送方只要一連收到三個重復確認就應當立即重傳對方尚未收到的報文段，而不必繼續(xù)等待設置的重傳計時器時間到期。
快速恢復（Fast Recovery）：當發(fā)送方連續(xù)收到三個重復確認時，就把慢開始門限ssthresh門限減半。接下來將cwnd設置為ssthresh的大小，然后執(zhí)行擁塞避免算法
擁塞控制和流量控制都是什么，兩者的區(qū)別？
擁塞控制：對網(wǎng)絡中的路由和鏈路傳輸進行速度限制，避免網(wǎng)絡過載；包含四個過程：慢啟動、擁塞避免、快重傳和快恢復。
流量控制 ：對點和點/發(fā)送方和接收方之間進行速度匹配，由于接收方的應用程序讀取速度不一定很迅速，加上緩存有限，因此需要避免發(fā)送速度過快。
為什么要3次握手，4次揮手
三次握手：防止已過期的連接請求報文突然又傳送到服務器，因而產(chǎn)生錯誤
四次揮手：確保數(shù)據(jù)能夠完成傳輸，但關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方?jīng)]有數(shù)據(jù)發(fā)送給你了；但未必你所有的數(shù)據(jù)都全部發(fā)送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發(fā)送一些數(shù)據(jù)給對方之后，再發(fā)送FIN報文給對方來表示你同意現(xiàn)在可以關閉連接了，所以它這里的ACK報文和FIN報文多數(shù)情況下都是分開發(fā)送的*
TCP協(xié)議如何來保證傳輸?shù)目煽啃?/h1>
數(shù)據(jù)包校驗：目的是檢測數(shù)據(jù)在傳輸過程中的任何變化，若校驗出包有錯，則丟棄報文段并且不給出響應，這時TCP發(fā)送數(shù)據(jù)端超時后會重發(fā)數(shù)據(jù)；
對失序數(shù)據(jù)包重排序：既然TCP報文段作為IP數(shù)據(jù)報來傳輸，而IP數(shù)據(jù)報的到達可能會失序，因此TCP報文段的到達也可能會失序。TCP將對失序數(shù)據(jù)進行重新排序，然后才交給應用層；
丟棄重復數(shù)據(jù)：對于重復數(shù)據(jù)，能夠丟棄重復數(shù)據(jù)；
應答機制：當TCP收到發(fā)自TCP連接另一端的數(shù)據(jù)，它將發(fā)送一個確認。這個確認不是立即發(fā)送，通常將推遲幾分之一秒；
超時重發(fā)：當TCP發(fā)出一個段后，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發(fā)這個報文段；
流量控制：TCP連接的每一方都有固定大小的緩沖空間。TCP的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)，這可以防止較快主機致使較慢主機的緩沖區(qū)溢出，這就是流量控制。TCP使用的流量控制協(xié)議是可變大小的滑動窗口協(xié)議。
HTTP基本格式
HTTP請求
HTTP響應
GET、POST區(qū)別
一般用于獲取/查詢資源信息；GET參數(shù)通過URL傳遞，傳遞的參數(shù)是有長度限制，不能用來傳遞敏感信息。
當客戶端給服務器提供信息較多時可以使用POST；POST會附帶用戶數(shù)據(jù)，一般用于更新資源信息；POST將請求參數(shù)封裝在HTTP 請求數(shù)據(jù)中，可以傳輸大量數(shù)據(jù)，傳參方式比GET更安全。
HTTP 、TCP、Socket區(qū)別
TCP/IP代表傳輸控制協(xié)議/網(wǎng)際協(xié)議，指的是一系列協(xié)組
HTTP本身就是一個協(xié)議，是從Web服務器傳輸超文本到本地瀏覽器的傳送協(xié)議
Socket是TCP/IP網(wǎng)絡的API其實就是一個門面模式，它把復雜的TCP/IP協(xié)議族隱藏在Socket接口后面，對用戶來說，一組簡單的接口就是全部，讓Socket去組織數(shù)據(jù)，以符合指定的協(xié)議
綜上所述：需要IP協(xié)議來連接網(wǎng)絡;TCP是一種允許我們安全傳輸數(shù)據(jù)的機制，使用TCP協(xié)議來傳輸數(shù)據(jù)的HTTP是Web服務器和客戶端使用的特殊協(xié)議。HTTP基于TCP協(xié)議，但是卻可以使用socket去建立一個TCP連接
Cookies 和 Session的區(qū)別
cookie 是一種發(fā)送到客戶瀏覽器的文本串句柄，并保存在客戶機硬盤上，可以用來在某個WEB站點會話間持久的保持數(shù)據(jù)
session其實指的就是訪問者從到達某個特定主頁到離開為止的那段時間。 Session其實是利用Cookie進行信息處理的，當用戶首先進行了請求后，服務端就在用戶瀏覽器上創(chuàng)建了一個Cookie，當這個Session結束時，其實就是意味著這個Cookie就過期了
cookie數(shù)據(jù)保存在客戶端，session數(shù)據(jù)保存在服務器端*
一次完整的HTTP請求所經(jīng)歷的步驟
1. DNS解析(通過訪問的域名找出其IP地址，遞歸搜索)
2. HTTP請求，當輸入一個請求時，建立一個Socket連接發(fā)起TCP的3次握手
3. 如果是HTTPS請求建立連接后，則看Q26
4. 客戶端向服務器發(fā)送請求命令（一般是GET或POST請求）
5. 客戶端發(fā)送請求頭信息
6. 服務器發(fā)送應答頭信息
7. 服務器向客戶端發(fā)送數(shù)據(jù)
8. 服務器關閉TCP連接（4次揮手）
9. 客戶端根據(jù)返回的HTML，CSS，JS進行渲染
為什么要用HTTPS?
- 通信使用明文(不加密)，內(nèi)容可能被竊聽(抓包工具可以獲取請求和響應內(nèi)容)
- 不驗證通訊方的身分，任何人都坑你發(fā)送請求，不管對方是誰都返回相應
- 無法證明報文的完整性，可能會遭到篡改，即沒有辦法確認發(fā)出的請求/相應前后一致*
HTTP與HTTPS的相同和異同點
1. HTTPS需要用到CA申請證書
2. HTTP是超文本傳輸協(xié)議，信息是明文的；HTTPS則是具有安全性的SSL加密傳輸協(xié)議
3. HTTP是80,HTTPS是443
4. HTTP的連接很簡單，是無狀態(tài)的，HTTPS是HTTP+SSL協(xié)議構建的，可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，比HTTP協(xié)議安全*
加密&證書
1. 加密方法：
* 對稱加密(加密和解密使用相同的密鑰的加密算法) :DES(Data Encryption Standard)、AES(Advanced Encryption Standard)、RC4、IDEA
* 非對稱加密（非對稱加密算法有兩個密鑰：公開密鑰(public key）和私有密鑰(private key)；并且加密密鑰和解密密鑰是成對出現(xiàn)的）：RSA、DSA/DSS
* 不可逆加密：數(shù)字摘要是采用單項Hash函數(shù)將需要加密的明文"摘要"成一串固定長度(128位)的密文，“數(shù)字摘要”是https能確保數(shù)據(jù)完整性和防篡改的根本原因。常用的摘要主要有MD5、SHA1、SHA256等。
2. 數(shù)字簽名：
數(shù)字簽名技術就是對"非對稱"和"數(shù)字摘要"兩項技術的應用，它將摘要信息用發(fā)送者的私鑰加密，與原文一起傳送給接受者。接受者只有用發(fā)送者的公鑰才能解密被加密的摘要信息，然后用HASH函數(shù)對收到的原因產(chǎn)生一個摘要信息，與解密的摘要信息對比。如果相同，則說明收到的信息是完整的，在傳輸?shù)倪^程中沒有被修改，否則說明信息被修改過，因此數(shù)字簽名能夠驗證信息的完整性。明文——>hash運算——>摘要——>私鑰加密——>數(shù)字簽名
3. 數(shù)字證書
使用HTTPS方式與Web服務器通信時有以下幾個步驟(HTTPS協(xié)議是由SSL+HTTP協(xié)議構建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，要比http協(xié)議安全)
1. 客戶使用https的URL訪問Web服務器，要求與Web服務器建立SSL連接（通知可加密的算法）。
2. Web服務器收到客戶端請求后，會將網(wǎng)站的電子證書（證書中包含公鑰）傳送一份給客戶端。
3. 客戶端確認電子證書是否剛才訪問網(wǎng)站所屬
4. 客戶端的瀏覽器根據(jù)雙方同意的安全等級，建立會話密鑰，然后利用網(wǎng)站的公鑰將會話密鑰加密，并傳送給網(wǎng)站。
5. Web服務器利用自己的私鑰解密出會話密鑰（客戶端發(fā)來的對稱加密密鑰）。
6. Web服務器利用對稱密鑰加密與客戶端之間的通信。* ### HTTPS的結構圖
TLS/SSL 原理
1. SSL(Secure Sokcet Layer，安全套接字層)
2. TLS(Transport Layer Security,傳輸層安全協(xié)議)
HTTPS與代理
1. 代理作用：提高訪問速度、Proxy可以起到防火墻的作用、通過代理服務器訪問一些不能直接訪問的網(wǎng)站、安全性得到提高
SPDY
1. SPDY可以說是綜合了HTTPS和HTTP兩者有點于一體的傳輸協(xié)議
2. 降低延遲、請求優(yōu)先級、header壓縮、服務端推送* ### HTTP2.0
播放視頻用TCP還是UDP？為什么？
播放視頻適合用UDP。UDP適用于對網(wǎng)絡通訊質(zhì)量要求不高、要求網(wǎng)絡通訊速度能盡量快的實時性應用；而TCP適用于對網(wǎng)絡通訊質(zhì)量有要求的可靠性應用。
get和post的區(qū)別？
HTTP和TCP的區(qū)別
TCP是傳輸層協(xié)議，定義數(shù)據(jù)傳輸和連接方式的規(guī)范。通過三次握手建立連接、四次揮手釋放連接。
HTTP是應用層協(xié)議，定義的是傳輸數(shù)據(jù)的內(nèi)容的規(guī)范。HTTP的連接使用"請求-響應"方式?；赥CP協(xié)議傳輸。
HTTP和Socket的區(qū)別
HTTP是應用層協(xié)議；基于TCP協(xié)議；使用“請求—響應”方式建立連接，在請求時需要先建立連接且客戶端要先發(fā)出請求，可見服務器需要等到客戶端發(fā)送一次請求后才能將數(shù)據(jù)傳回給客戶端。
Socket（套接字）是對TCP/IP協(xié)議的封裝，是接口而不是協(xié)議；創(chuàng)建Socket連接時可以指定傳輸層協(xié)議TCP或UDP；Socket建立連接過程三步驟：服務器監(jiān)聽->客戶端請求->連接確認，可見服務器可以直接將數(shù)據(jù)傳送給客戶端。
Http和Https的區(qū)別
端口不同：Http與Http使用不同的連接方式，用的端口也不一樣，前者是80，后者是443；
資源消耗：和HTTP通信相比，Https通信會由于加減密處理消耗更多的CPU和內(nèi)存資源；
開銷：Https通信需要證書，而證書一般需要向認證機構購買；
DDos 攻擊
客戶端向服務端發(fā)送請求鏈接數(shù)據(jù)包
服務端向客戶端發(fā)送確認數(shù)據(jù)包
客戶端不向服務端發(fā)送確認數(shù)據(jù)包，服務器一直等待來自客戶端的確認
DDos 預防 ( 沒有徹底根治的辦法，除非不使用TCP )
限制同時打開SYN半鏈接的數(shù)目
縮短SYN半鏈接的Time out 時間
關閉不必要的服務
Get與POST的區(qū)別
從功能上講，GET一般用來從服務器上獲取資源，POST一般用來更新服務器上的資源；
從REST服務角度上說，GET是冪等的，即讀取同一個資源，總是得到相同的數(shù)據(jù)，而POST不是冪等的，因為每次請求對資源的改變并不是相同的；進一步地，GET不會改變服務器上的資源，而POST會對服務器資源進行改變；
從請求參數(shù)形式上看，GET請求的數(shù)據(jù)會附在URL之后，即將請求數(shù)據(jù)放置在HTTP報文的 請求頭 中，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連。特別地，如果數(shù)據(jù)是英文字母/數(shù)字，原樣發(fā)送；否則，會將其編碼為 application/x-www-form-urlencoded MIME 字符串(如果是空格，轉(zhuǎn)換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號以16進制表示的ASCII)；而POST請求會把提交的數(shù)據(jù)則放置在是HTTP請求報文的 請求體 中。
就安全性而言，POST的安全性要比GET的安全性高，因為GET請求提交的數(shù)據(jù)將明文出現(xiàn)在URL上，而且POST請求參數(shù)則被包裝到請求體中，相對更安全。
從請求的大小看，GET請求的長度受限于瀏覽器或服務器對URL長度的限制，允許發(fā)送的數(shù)據(jù)量比較小，而POST請求則是沒有大小限制的。
TCP和UDP分別對應的常見應用層協(xié)議
TCP對應的應用層協(xié)議
FTP：定義了文件傳輸協(xié)議，使用21端口。常說某某計算機開了FTP服務便是啟動了文件傳輸服務。下載文件，上傳主頁，都要用到FTP服務。
Telnet：它是一種用于遠程登陸的端口，用戶可以以自己的身份遠程連接到計算機上，通過這種端口可以提供一種基于DOS模式下的通信服務。如以前的BBS是-純字符界面的，支持BBS的服務器將23端口打開，對外提供服務。
SMTP：定義了簡單郵件傳送協(xié)議，現(xiàn)在很多郵件服務器都用的是這個協(xié)議，用于發(fā)送郵件。如常見的免費郵件服務中用的就是這個郵件服務端口，所以在電子郵件設置-中?？吹接羞@么SMTP端口設置這個欄，服務器開放的是25號端口。
POP3：它是和SMTP對應，POP3用于接收郵件。通常情況下，POP3協(xié)議所用的是110端口。也是說，只要你有相應的使用POP3協(xié)議的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陸進郵箱界面，直接用郵件程序就可以收到郵件（如是163郵箱就沒有必要先進入網(wǎng)易網(wǎng)站，再進入自己的郵-箱來收信）。
HTTP：從Web服務器傳輸超文本到本地瀏覽器的傳送協(xié)議。
UDP對應的應用層協(xié)議
DNS：用于域名解析服務，將域名地址轉(zhuǎn)換為IP地址。DNS用的是53號端口。
SNMP：簡單網(wǎng)絡管理協(xié)議，使用161號端口，是用來管理網(wǎng)絡設備的。由于網(wǎng)絡設備很多，無連接的服務就體現(xiàn)出其優(yōu)勢。
TFTP(Trival File Transfer Protocal)：簡單文件傳輸協(xié)議，該協(xié)議在熟知端口69上使用UDP服務
** 79. http 響應碼 301 和 302 代表的是什么？有什么區(qū)別？**
答：301，302 都是HTTP狀態(tài)的編碼，都代表著某個URL發(fā)生了轉(zhuǎn)移。
**區(qū)別： **
301 redirect: 301 代表永久性轉(zhuǎn)移(Permanently Moved)。
302 redirect: 302 代表暫時性轉(zhuǎn)移(Temporarily Moved )。
80. forward 和 redirect 的區(qū)別？
Forward和Redirect代表了兩種請求轉(zhuǎn)發(fā)方式：直接轉(zhuǎn)發(fā)和間接轉(zhuǎn)發(fā)。
直接轉(zhuǎn)發(fā)方式（Forward），客戶端和瀏覽器只發(fā)出一次請求，Servlet、HTML、JSP或其它信息資源，由第二個信息資源響應該請求，在請求對象request中，保存的對象對于每個信息資源是共享的。
間接轉(zhuǎn)發(fā)方式（Redirect）實際是兩次HTTP請求，服務器端在響應第一次請求的時候，讓瀏覽器再向另外一個URL發(fā)出請求，從而達到轉(zhuǎn)發(fā)的目的。
舉個通俗的例子：
直接轉(zhuǎn)發(fā)就相當于：“A找B借錢，B說沒有，B去找C借，借到借不到都會把消息傳遞給A”；
間接轉(zhuǎn)發(fā)就相當于："A找B借錢，B說沒有，讓A去找C借"。
81. 簡述 tcp 和 udp的區(qū)別？
TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。
TCP提供可靠的服務。也就是說，通過TCP連接傳送的數(shù)據(jù)，無差錯，不丟失，不重復，且按序到達;UDP盡最大努力交付，即不保證可靠交付。
Tcp通過校驗和，重傳控制，序號標識，滑動窗口、確認應答實現(xiàn)可靠傳輸。如丟包時的重發(fā)控制，還可以對次序亂掉的分包進行順序控制。
UDP具有較好的實時性，工作效率比TCP高，適用于對高速傳輸和實時性有較高的通信或廣播通信。
每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信。
TCP對系統(tǒng)資源要求較多，UDP對系統(tǒng)資源要求較少。
83. 說一下 tcp 粘包是怎么產(chǎn)生的？
①. 發(fā)送方產(chǎn)生粘包
采用TCP協(xié)議傳輸數(shù)據(jù)的客戶端與服務器經(jīng)常是保持一個長連接的狀態(tài)（一次連接發(fā)一次數(shù)據(jù)不存在粘包），雙方在連接不斷開的情況下，可以一直傳輸數(shù)據(jù)；但當發(fā)送的數(shù)據(jù)包過于的小時，那么TCP協(xié)議默認的會啟用Nagle算法，將這些較小的數(shù)據(jù)包進行合并發(fā)送（緩沖區(qū)數(shù)據(jù)發(fā)送是一個堆壓的過程）；這個合并過程就是在發(fā)送緩沖區(qū)中進行的，也就是說數(shù)據(jù)發(fā)送出來它已經(jīng)是粘包的狀態(tài)了。
②. 接收方產(chǎn)生粘包
接收方采用TCP協(xié)議接收數(shù)據(jù)時的過程是這樣的：數(shù)據(jù)到底接收方，從網(wǎng)絡模型的下方傳遞至傳輸層，傳輸層的TCP協(xié)議處理是將其放置接收緩沖區(qū)，然后由應用層來主動獲?。–語言用recv、read等函數(shù)）；這時會出現(xiàn)一個問題，就是我們在程序中調(diào)用的讀取數(shù)據(jù)函數(shù)不能及時的把緩沖區(qū)中的數(shù)據(jù)拿出來，而下一個數(shù)據(jù)又到來并有一部分放入的緩沖區(qū)末尾，等我們讀取數(shù)據(jù)時就是一個粘包。（放數(shù)據(jù)的速度 > 應用層拿數(shù)據(jù)速度）
get 和 post 請求有哪些區(qū)別？
GET在瀏覽器回退時是無害的，而POST會再次提交請求。
GET產(chǎn)生的URL地址可以被Bookmark，而POST不可以。
GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。
GET請求只能進行url編碼，而POST支持多種編碼方式。
GET請求參數(shù)會被完整保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會被保留。
GET請求在URL中傳送的參數(shù)是有長度限制的，而POST么有。
對參數(shù)的數(shù)據(jù)類型，GET只接受ASCII字符，而POST沒有限制。
GET比POST更不安全，因為參數(shù)直接暴露在URL上，所以不能用來傳遞敏感信息。
GET參數(shù)通過URL傳遞，POST放在Request body中。
HTTP 和 TCP 有什么關系
http是在tcp基礎上的請求響應式協(xié)議。
tcp為傳輸層協(xié)議，http為應用層協(xié)議
HTTP 1.0 和 HTTP 1.1 的差別
http1.1增加了如下功能
可擴展性（1.1增加了版本號，OPTIONS，Upgrade等）
緩存強化（cache相關）
帶寬優(yōu)化（文件斷點續(xù)傳，range相關）
長連接（keep-alive相關）
host頭
身份認證，狀態(tài)管理
HTTP 頭部有哪些字段
舉例：
Expire
If-Modified-Since
Last-Modefied
Pragma:no-cache
ETag
If-None-Match
Cache-Control
Accept-Language
Accept-Charset
Content-Range
Transfer-Encoding
Origin
Host
User-Agent
Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Expose-Headers
Content-Type
為什么 HTTP 是無連接的
無連接的意思是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。與TCP連接不是同一個意思。
但實際上現(xiàn)在的HTTP支持keepalive等模式，支持單個連接處理多個請求應答。
有沒有保持長連接的 HTTP
HTTP1.1及更新的HTTP協(xié)議都支持keepalive長連接，甚至http2還支持服務端向客戶端推送數(shù)據(jù)
TCP 中客戶端發(fā)送 SYN 后客戶端和服務器分別處在什么狀態(tài)
客戶端SYN_SENT，服務端則接收到SYN并發(fā)出ACK后轉(zhuǎn)為SYN_RECV
服務器調(diào)用 send 后返回發(fā)送數(shù)據(jù)大小，是否可以認為客戶端已收到？如何確?？蛻舳耸盏綌?shù)據(jù)
send返回發(fā)送數(shù)據(jù)大小后，說明數(shù)據(jù)已經(jīng)到達或到達客戶端內(nèi)核緩存，但并不能表明客戶端的進程已經(jīng)拿到數(shù)據(jù)。如果需要確認對方客戶端進程收到，則需要與該進程在應用層實現(xiàn)相應的確認機制
304 狀態(tài)碼的意義？在 HTTP 協(xié)議中的實現(xiàn)
304校驗緩存：瀏覽器端cache的信息發(fā)送到服務器校驗，如果服務器認為cache依然有效，則返回304，瀏覽器可以繼續(xù)使用該cache
如何判斷服務器文件是否已修改？知道瀏覽器緩存的文件與服務器文件不一致？在 HTTP 中哪個字段（TODO））
304校驗時，客戶端發(fā)送條件請求，帶If-Modified-Since頭，值為服務器上次返回的Last-Modified頭中的時間，還會帶If-None-Match頭，值為服務器上次返回的ETag響應頭的值
A 類地址和 B 類地址的區(qū)別
