後端開發工程師面試題彙總 | 網絡知識

時間  2019-11-08
標籤 後端 開發 工程師 面試 彙總 網絡 知識 欄目 快樂工作 简体版
原文   原文鏈接

不管作前端開發仍是後端開發，網絡知識是必備的知識。這部分知識是基礎中的基礎，是咱們必須掌握的內容。網絡相關的問題也是在面試過程當中常常被問到的內容。本文主要梳理了一下網絡相關的主要知識點及面試中常常被問到的內容，但願對你們有所幫助。前端

OSI有哪幾層，會畫出來，知道主要幾層的各自做用

OSI（Open System Interconnect），即開放式系統互聯，是ISO（國際標準化組織）組織在1985年研究的網絡互連模型。其一共有7層： web

圖1 OSI分層 

1.  應用層（數據）：肯定進程之間通訊的性質以知足用戶須要以及提供網絡與用戶應用
2.  表示層（數據）：主要解決擁護信息的語法表示問題，如加密解密
3.  會話層（數據）：提供包括訪問驗證和會話管理在內的創建和維護應用之間通訊的機制，如服務器驗證用戶登陸即是由會話層完成的
4.  運輸層（段）：實現網絡不一樣主機上用戶進程之間的數據通訊，可靠
    與不可靠的傳輸，傳輸層的錯誤檢測，流量控制等
5.  網絡層（包）：提供邏輯地址（IP）、選路，數據從源端到目的端的
    傳輸
6.  數據鏈路層（幀）：將上層數據封裝成幀，用MAC地址訪問媒介，錯誤檢測與修正
7.  物理層（比特流）：設備之間比特流的傳輸，物理接口，電氣特性等*   
複製代碼

TCP/IP有哪幾層，會畫出來，知道全部層數的做用，會列舉各層主要的協議名稱

TCP/IP分層模型（TCP/IP Layening Model）被稱做因特網分層模型(Internet Layering Model)、因特網參考模型(Internet Reference Model)。 面試

圖2 TCP/IP網絡分層 

1.  應用層（TELNET、FTP、SMTP）
2.  運輸層（TCP、UDP）
3.  網際層（IP、ICMP）
4.  網絡接口層（PPP）*   
複製代碼

各個層使用的是哪一個數據交換設備。（交換機、路由器、網關）

在廣域網場景下，整個網絡傳輸須要通過不少設備，包括網關、交換機、路由器等等， 算法

圖3 交換設備示意圖

  1. 網關：應用層、傳輸層（網關在傳輸層上以實現網絡互連，是最複雜的網絡互連設備，僅用於兩個高層協議不一樣的網絡互連。網關的結構也和路由器相似，不一樣的是互連層。網關既能夠用於廣域網互連，也能夠用於局域網互連）
  2. 路由器：網絡層（路由選擇、存儲轉發）
  3. 交換機：數據鏈路層、網絡層（識別數據包中的MAC地址信息，根據MAC地址進行轉發，並將這些MAC地址與對應的端口記錄在本身內部的一個地址表中）
  4. 網橋：數據鏈路層（將兩個LAN連起來，根據MAC地址來轉發幀）
  5. 集線器（Hub）：物理層（純硬件設備，主要用來鏈接計算機等網絡終端）
  6. 中繼器：物理層（在比特級別對網絡信號進行再生和重定時，從而使得它們可以在網絡上傳輸更長的距離）

TCP協議是如何定義的，它的數據格式是什麼樣子的？

TCP是基於傳輸層的協議，協議文件可從RFC793獲得，使用普遍，面向鏈接的可靠協議。它能把報文分解爲數段，在目的站再從新裝配這些段，支持從新發送未被收到的段，提供兩臺設備間的全雙工鏈接，容許它們高效地交換大量數據。TCP使用滑動窗口協議來高效使用網絡。因爲TCP不多幹預底層投遞系統的工做，它適應各類投遞系統，且提供流量控制，能使各類不一樣速率的系統進行通訊。報文段是TCP所使用的基本傳輸單元，用於傳輸數據或控制信息。以下是TCP協議的報文格式： 編程

image

IP報文的格式，格式的各個字段的含義要理解

IP是Internet最基本的協議。IP是面向報文的協議，它獨立處理每一個報文包，每一個報文包必須含有完整的尋址信息。IP報文包的格式如圖所示： 後端

1.jpg

關於TCP/IP的內容，請參考本號以前的文章《從socket到TCP協議，透徹理解網絡編程》。瀏覽器

ICMP協議的主要功能

用於在IP主機、路由器之間傳遞控制消息 緩存

image

IP地址的分類，如何劃分的，及會計算各種地址支持的主機數

IP地址的類型共有4種（如圖3所示）：A類用於處理超大型網絡，最多16387064個主機（1～126）；B類網絡最多可有64516個主機（網絡地址的第一段爲128～191）；C類用於小型網絡，最多可有254個主機（網絡地址的第一段爲192～223）；D類用於多點播送，用於多目的信息的傳輸。全零（「0.0.0.0」）地址對應於當前主機，全1地址（「255.255.255.255」）是當前子網的廣播地址。安全

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
複製代碼

劃分子網、構造超網

  1. 劃分子網（變長子網掩碼VLSM）：劃分子網的方法是從網絡的主機號借用若干位做爲子網號subnet-id，與此同時主機號也減小相應位數（總位數32位不變）。由此兩級IP地址可變爲三級IP地址： IP地址 ::= {<網絡號>,<子網號>,<主機號>}，劃分子網只是把IP地址的主機號這部分進行再劃分，並不改變IP地址原來的網絡號
  2. 構造超網（無分類編址CIDR）：CIDR消除了傳統的A類、B類和C類地址以及劃分子網的概念，把32位的IP地址劃分爲兩個部分。如：128.14.35.7/20是某個CIDR地址塊中的一個地址，其前20位是網絡前綴（用下劃線表示的部分），後面的12位爲主機號*

DNS的概念，用途，DNS查詢的實現算法

  • 概念 域名解析，www.xxx.com轉換成ip，可以使用戶更方便的訪問互聯網，而不用去記住可以被機器直接讀取的ip數串 DNS協議運行在UDP協議之上，使用端口號53
  • 主機解析域名的順序
    1. 瀏覽器緩存
    2. 找本機的hosts文件
    3. 路由緩存
    4. 找DNS服務器(本地域名、頂級域名、根域名)
    5. 迭代查詢、遞歸查詢*

常見熟知端口

image

TCP與UDP的概念相互的區別及優劣

1.  TCP面向鏈接，UDP面向無連接
2.  TCP面向報文，UDP面向字節流
3.  TCP提供可靠傳輸服務（數據順序、正確性），UDP傳輸不可靠
4.  TCP協議傳輸速度慢，UDP協議傳輸速度快
5.  TCP協議對系統資源要求多（頭部開銷大），UDP協議要求少*   
複製代碼

UDP報文的格式，字段的意義

UDP 是User Datagram Protocol的簡稱， 中文名是用戶數據報協議，是OSI（Open System Interconnection，開放式系統互聯） 參考模型中一種無鏈接的傳輸層協議，提供面向事務的簡單不可靠信息傳送服務，IETF RFC 768是UDP的正式規範。 服務器

圖 UDP報文格式
UDP經過IP協議進行數據傳輸，如圖是二者之間的關係。
圖 UDP與IP的關係

TCP報文的格式，字段的意義

image

TCP經過哪些措施，保證傳輸可靠

1.  流量控制
2.  讓發送方的發送速率不要太快，要讓接收方來得及接收
3.  窗口大小是一個能夠改變的值，它由接收端主機控制，附加在 TCP 首部的「窗口大小」字段中
4.  擁塞控制
5.  防止過多的數據注入到網絡中，這樣可使網絡中的路由器或鏈路不致過載
6.  擁塞控制方法：慢開始、擁塞避免、快重傳和快恢復*   ### 三次握手，四次斷開過程
複製代碼

image.png

請求各個狀態的意義以下

image.png 

1.  LISTEN - 偵聽來自遠方TCP端口的鏈接請求；
2.  SYN-SENT -在發送鏈接請求後等待匹配的鏈接請求；
3.  SYN-RECEIVED - 在收到和發送一個鏈接請求後等待對鏈接請求的確認；
4.  ESTABLISHED- 表明一個打開的鏈接，數據能夠傳送給用戶；
5.  FIN-WAIT-1 - 等待遠程TCP的鏈接中斷請求，或先前的鏈接中斷請求的確認；
6.  FIN-WAIT-2 - 從遠程TCP等待鏈接中斷請求；
7.  CLOSE-WAIT - 等待從本地用戶發來的鏈接中斷請求；
8.  CLOSING -等待遠程TCP對鏈接中斷的確認；
9.  LAST-ACK - 等待原來發向遠程TCP的鏈接中斷請求的確認；
10.  TIME-WAIT -等待足夠的時間以確保遠程TCP接收到鏈接中斷請求的確認；
11.  CLOSED - 沒有任何鏈接狀態；*  
複製代碼

TCP 的擁塞控制是怎樣的

擁塞算法：

慢啓動（Slow Start）發送方維護擁塞窗口變量cwnd，先用小數據試探網絡擁塞，沒問題後來斷加倍 擁塞避免（Congestion voidance）：擁塞窗口緩慢增加，即每通過一個往返時間RTT就把發送方的擁塞窗口cwnd加1 重傳機制 快速重傳（Fast Retransmit）：快重傳要求接收方收到失序報文段後當即發出重複確認（爲的是使發送方及早知道有報文段沒有到達對方）而不要等到本身發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重複確認就應當當即重傳對方還沒有收到的報文段，而沒必要繼續等待設置的重傳計時器時間到期。 快速恢復（Fast Recovery）：當發送方連續收到三個重複確認時，就把慢開始門限ssthresh門限減半。接下來將cwnd設置爲ssthresh的大小，而後執行擁塞避免算法

擁塞控制和流量控制都是什麼，二者的區別？

擁塞控制：對網絡中的路由和鏈路傳輸進行速度限制，避免網絡過載；包含四個過程：慢啓動、擁塞避免、快重傳和快恢復。 流量控制 ：對點和點/發送方和接收方之間進行速度匹配，因爲接收方的應用程序讀取速度不必定很迅速，加上緩存有限，所以須要避免發送速度過快。

爲何要3次握手，4次揮手

三次握手：防止已過時的鏈接請求報文忽然又傳送到服務器，於是產生錯誤 四次揮手：確保數據可以完成傳輸，但關閉鏈接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你全部的數據都所有發送給對方了，因此你能夠未必會立刻會關閉SOCKET,也即你可能還須要發送一些數據給對方以後，再發送FIN報文給對方來表示你贊成如今能夠關閉鏈接了，因此它這裏的ACK報文和FIN報文多數狀況下都是分開發送的*

TCP協議如何來保證傳輸的可靠性

數據包校驗：目的是檢測數據在傳輸過程當中的任何變化，若校驗出包有錯，則丟棄報文段而且不給出響應，這時TCP發送數據端超時後會重發數據； 對失序數據包重排序：既然TCP報文段做爲IP數據報來傳輸，而IP數據報的到達可能會失序，所以TCP報文段的到達也可能會失序。TCP將對失序數據進行從新排序，而後才交給應用層； 丟棄重複數據：對於重複數據，可以丟棄重複數據； 應答機制：當TCP收到發自TCP鏈接另外一端的數據，它將發送一個確認。這個確認不是當即發送，一般將推遲幾分之一秒； 超時重發：當TCP發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。若是不能及時收到一個確認，將重發這個報文段； 流量控制：TCP鏈接的每一方都有固定大小的緩衝空間。TCP的接收端只容許另外一端發送接收端緩衝區所能接納的數據，這能夠防止較快主機導致較慢主機的緩衝區溢出，這就是流量控制。TCP使用的流量控制協議是可變大小的滑動窗口協議。

HTTP基本格式

HTTP請求

image

HTTP響應

image

GET、POST區別

通常用於獲取/查詢資源信息；GET參數經過URL傳遞，傳遞的參數是有長度限制，不能用來傳遞敏感信息。 當客戶端給服務器提供信息較多時可使用POST；POST會附帶用戶數據，通常用於更新資源信息；POST將請求參數封裝在HTTP 請求數據中，能夠傳輸大量數據，傳參方式比GET更安全。

image

HTTP 、TCP、Socket區別

TCP/IP表明傳輸控制協議/網際協議，指的是一系列協組

HTTP自己就是一個協議，是從Web服務器傳輸超文本到本地瀏覽器的傳送協議

Socket是TCP/IP網絡的API其實就是一個門面模式，它把複雜的TCP/IP協議族隱藏在Socket接口後面，對用戶來講，一組簡單的接口就是所有，讓Socket去組織數據，以符合指定的協議

綜上所述：須要IP協議來鏈接網絡;TCP是一種容許咱們安全傳輸數據的機制，使用TCP協議來傳輸數據的HTTP是Web服務器和客戶端使用的特殊協議。HTTP基於TCP協議，可是卻可使用socket去創建一個TCP鏈接

Cookies 和 Session的區別

cookie 是一種發送到客戶瀏覽器的文本串句柄，並保存在客戶機硬盤上，能夠用來在某個WEB站點會話間持久的保持數據 session其實指的就是訪問者從到達某個特定主頁到離開爲止的那段時間。 Session實際上是利用Cookie進行信息處理的，當用戶首先進行了請求後，服務端就在用戶瀏覽器上建立了一個Cookie，當這個Session結束時，其實就是意味着這個Cookie就過時了 cookie數據保存在客戶端，session數據保存在服務器端*

一次完整的HTTP請求所經歷的步驟

圖3 HTTP請求過程分析 

1.  DNS解析(經過訪問的域名找出其IP地址，遞歸搜索)
2.  HTTP請求，當輸入一個請求時，創建一個Socket鏈接發起TCP的3次握手
3.  若是是HTTPS請求創建鏈接後，則看Q26
4.  客戶端向服務器發送請求命令（通常是GET或POST請求）
5.  客戶端發送請求頭信息
6.  服務器發送應答頭信息
7.  服務器向客戶端發送數據
8.  服務器關閉TCP鏈接（4次揮手）
9.  客戶端根據返回的HTML，CSS，JS進行渲染
複製代碼

爲何要用HTTPS?

  1. 通訊使用明文(不加密)，內容可能被竊聽(抓包工具能夠獲取請求和響應內容)
  2. 不驗證通信方的身分，任何人都坑你發送請求，無論對方是誰都返回相應
  3. 沒法證實報文的完整性，可能會遭到篡改，即沒有辦法確認發出的請求/相應先後一致*

HTTP與HTTPS的相同和異同點

1.  HTTPS須要用到CA申請證書
2.  HTTP是超文本傳輸協議，信息是明文的；HTTPS則是具備安全性的SSL加密傳輸協議
3.  HTTP是80,HTTPS是443
4.  HTTP的鏈接很簡單，是無狀態的，HTTPS是HTTP+SSL協議構建的，可進行加密傳輸、身份認證的網絡協議，比HTTP協議安全*   
複製代碼

加密&證書

1.  加密方法：

    *   對稱加密(加密和解密使用相同的密鑰的加密算法) :DES(Data Encryption Standard)、AES(Advanced Encryption Standard)、RC四、IDEA
    *   非對稱加密（非對稱加密算法有兩個密鑰：公開密鑰(public key）和私有密鑰(private key)；而且加密密鑰和解密密鑰是成對出現的）：RSA、DSA/DSS
    *   不可逆加密：數字摘要是採用單項Hash函數將須要加密的明文"摘要"成一串固定長度(128位)的密文，「數字摘要」是https能確保數據完整性和防篡改的根本緣由。經常使用的摘要主要有MD五、SHA一、SHA256等。
2.  數字簽名：
    數字簽名技術就是對"非對稱"和"數字摘要"兩項技術的應用，它將摘要信息用發送者的私鑰加密，與原文一塊兒傳送給接受者。接受者只有用發送者的公鑰才能解密被加密的摘要信息，而後用HASH函數對收到的緣由產生一個摘要信息，與解密的摘要信息對比。若是相同，則說明收到的信息是完整的，在傳輸的過程當中沒有被修改，不然說明信息被修改過，所以數字簽名可以驗證信息的完整性。明文——>hash運算——>摘要——>私鑰加密——>數字簽名

3.  數字證書
複製代碼

使用HTTPS方式與Web服務器通訊時有如下幾個步驟(HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全)

1.  客戶使用https的URL訪問Web服務器，要求與Web服務器創建SSL鏈接（通知可加密的算法）。
2.  Web服務器收到客戶端請求後，會將網站的電子證書（證書中包含公鑰）傳送一份給客戶端。
3.  客戶端確認電子證書是否剛纔訪問網站所屬
4.  客戶端的瀏覽器根據雙方贊成的安全等級，創建會話密鑰，而後利用網站的公鑰將會話密鑰加密，並傳送給網站。
5.  Web服務器利用本身的私鑰解密出會話密鑰（客戶端發來的對稱加密密鑰）。
6.  Web服務器利用對稱密鑰加密與客戶端之間的通訊。*   ### HTTPS的結構圖

![image](//upload-images.jianshu.io/upload_images/2979410-73b3c96ec301dd32.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/946/format/webp)
複製代碼

TLS/SSL 原理

1.  SSL(Secure Sokcet Layer，安全套接字層)
2.  TLS(Transport Layer Security,傳輸層安全協議)

    ![image](//upload-images.jianshu.io/upload_images/2979410-3c7ed47912a40f33.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1000/format/webp)
複製代碼

HTTPS與代理

1.  代理做用：提升訪問速度、Proxy能夠起到防火牆的做用、經過代理服務器訪問一些不能直接訪問的網站、安全性獲得提升

    ![image](//upload-images.jianshu.io/upload_images/2979410-07c146f0ef4788ac.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/803/format/webp)
複製代碼

SPDY

1.  SPDY能夠說是綜合了HTTPS和HTTP二者有點於一體的傳輸協議
2.  下降延遲、請求優先級、header壓縮、服務端推送*   ### HTTP2.0
複製代碼

image

播放視頻用TCP仍是UDP？爲何？

播放視頻適合用UDP。UDP適用於對網絡通信質量要求不高、要求網絡通信速度能儘可能快的實時性應用；而TCP適用於對網絡通信質量有要求的可靠性應用。

get和post的區別？

HTTP和TCP的區別

TCP是傳輸層協議，定義數據傳輸和鏈接方式的規範。經過三次握手創建鏈接、四次揮手釋放鏈接。 HTTP是應用層協議，定義的是傳輸數據的內容的規範。HTTP的鏈接使用"請求-響應"方式。基於TCP協議傳輸。

HTTP和Socket的區別

HTTP是應用層協議；基於TCP協議；使用「請求—響應」方式創建鏈接，在請求時須要先創建鏈接且客戶端要先發出請求，可見服務器須要等到客戶端發送一次請求後才能將數據傳回給客戶端。 Socket（套接字）是對TCP/IP協議的封裝，是接口而不是協議；建立Socket鏈接時能夠指定傳輸層協議TCP或UDP；Socket創建鏈接過程三步驟：服務器監聽->客戶端請求->鏈接確認，可見服務器能夠直接將數據傳送給客戶端。

Http和Https的區別

端口不一樣：Http與Http使用不一樣的鏈接方式，用的端口也不同，前者是80，後者是443； 資源消耗：和HTTP通訊相比，Https通訊會因爲加減密處理消耗更多的CPU和內存資源； 開銷：Https通訊須要證書，而證書通常須要向認證機構購買；

DDos 攻擊

客戶端向服務端發送請求連接數據包 服務端向客戶端發送確認數據包 客戶端不向服務端發送確認數據包，服務器一直等待來自客戶端的確認

DDos 預防 ( 沒有完全根治的辦法，除非不使用TCP )

限制同時打開SYN半連接的數目 縮短SYN半連接的Time out 時間 關閉沒必要要的服務

Get與POST的區別

從功能上講，GET通常用來從服務器上獲取資源，POST通常用來更新服務器上的資源； 從REST服務角度上說，GET是冪等的，即讀取同一個資源，老是獲得相同的數據，而POST不是冪等的，由於每次請求對資源的改變並非相同的；進一步地，GET不會改變服務器上的資源，而POST會對服務器資源進行改變； 從請求參數形式上看，GET請求的數據會附在URL以後，即將請求數據放置在HTTP報文的 請求頭 中，以?分割URL和傳輸數據，參數之間以&相連。特別地，若是數據是英文字母/數字，原樣發送；不然，會將其編碼爲 application/x-www-form-urlencoded MIME 字符串(若是是空格，轉換爲+，若是是中文/其餘字符，則直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX爲該符號以16進製表示的ASCII)；而POST請求會把提交的數據則放置在是HTTP請求報文的 請求體 中。 就安全性而言，POST的安全性要比GET的安全性高，由於GET請求提交的數據將明文出如今URL上，並且POST請求參數則被包裝到請求體中，相對更安全。 從請求的大小看，GET請求的長度受限於瀏覽器或服務器對URL長度的限制，容許發送的數據量比較小，而POST請求則是沒有大小限制的。

TCP和UDP分別對應的常見應用層協議 TCP對應的應用層協議

FTP：定義了文件傳輸協議，使用21端口。常說某某計算機開了FTP服務即是啓動了文件傳輸服務。下載文件，上傳主頁，都要用到FTP服務。 Telnet：它是一種用於遠程登錄的端口，用戶能夠以本身的身份遠程鏈接到計算機上，經過這種端口能夠提供一種基於DOS模式下的通訊服務。如之前的BBS是-純字符界面的，支持BBS的服務器將23端口打開，對外提供服務。 SMTP：定義了簡單郵件傳送協議，如今不少郵件服務器都用的是這個協議，用於發送郵件。如常見的免費郵件服務中用的就是這個郵件服務端口，因此在電子郵件設置-中常看到有這麼SMTP端口設置這個欄，服務器開放的是25號端口。 POP3：它是和SMTP對應，POP3用於接收郵件。一般狀況下，POP3協議所用的是110端口。也是說，只要你有相應的使用POP3協議的程序（例如Fo-xmail或Outlook），就能夠不以Web方式登錄進郵箱界面，直接用郵件程序就能夠收到郵件（如是163郵箱就沒有必要先進入網易網站，再進入本身的郵-箱來收信）。 HTTP：從Web服務器傳輸超文本到本地瀏覽器的傳送協議。

UDP對應的應用層協議

DNS：用於域名解析服務，將域名地址轉換爲IP地址。DNS用的是53號端口。 SNMP：簡單網絡管理協議，使用161號端口，是用來管理網絡設備的。因爲網絡設備不少，無鏈接的服務就體現出其優點。 TFTP(Trival File Transfer Protocal)：簡單文件傳輸協議，該協議在熟知端口69上使用UDP服務

** 79. http 響應碼 301 和 302 表明的是什麼？有什麼區別？**

答：301，302 都是HTTP狀態的編碼，都表明着某個URL發生了轉移。

**區別： **

301 redirect: 301 表明永久性轉移(Permanently Moved)。

302 redirect: 302 表明暫時性轉移(Temporarily Moved )。

80. forward 和 redirect 的區別？

Forward和Redirect表明了兩種請求轉發方式：直接轉發和間接轉發。

直接轉發方式（Forward），客戶端和瀏覽器只發出一次請求，Servlet、HTML、JSP或其它信息資源，由第二個信息資源響應該請求，在請求對象request中，保存的對象對於每一個信息資源是共享的。

**間接轉發方式（Redirect）**實際是兩次HTTP請求，服務器端在響應第一次請求的時候，讓瀏覽器再向另一個URL發出請求，從而達到轉發的目的。

舉個通俗的例子：

直接轉發就至關於：「A找B借錢，B說沒有，B去找C借，借到借不到都會把消息傳遞給A」；

間接轉發就至關於："A找B借錢，B說沒有，讓A去找C借"。

81. 簡述 tcp 和 udp的區別？

TCP面向鏈接（如打電話要先撥號創建鏈接）;UDP是無鏈接的，即發送數據以前不須要創建鏈接。

TCP提供可靠的服務。也就是說，經過TCP鏈接傳送的數據，無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，即不保證可靠交付。

Tcp經過校驗和，重傳控制，序號標識，滑動窗口、確認應答實現可靠傳輸。如丟包時的重發控制，還能夠對次序亂掉的分包進行順序控制。

UDP具備較好的實時性，工做效率比TCP高，適用於對高速傳輸和實時性有較高的通訊或廣播通訊。

每一條TCP鏈接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通訊。

TCP對系統資源要求較多，UDP對系統資源要求較少。

83. 說一下 tcp 粘包是怎麼產生的？

①. 發送方產生粘包

採用TCP協議傳輸數據的客戶端與服務器常常是保持一個長鏈接的狀態（一次鏈接發一次數據不存在粘包），雙方在鏈接不斷開的狀況下，能夠一直傳輸數據；但當發送的數據包過於的小時，那麼TCP協議默認的會啓用Nagle算法，將這些較小的數據包進行合併發送（緩衝區數據發送是一個堆壓的過程）；這個合併過程就是在發送緩衝區中進行的，也就是說數據發送出來它已是粘包的狀態了。

image

②. 接收方產生粘包

接收方採用TCP協議接收數據時的過程是這樣的：數據到底接收方，從網絡模型的下方傳遞至傳輸層，傳輸層的TCP協議處理是將其放置接收緩衝區，而後由應用層來主動獲取（C語言用recv、read等函數）；這時會出現一個問題，就是咱們在程序中調用的讀取數據函數不能及時的把緩衝區中的數據拿出來，而下一個數據又到來並有一部分放入的緩衝區末尾，等咱們讀取數據時就是一個粘包。（放數據的速度 > 應用層拿數據速度）

image

get 和 post 請求有哪些區別？

GET在瀏覽器回退時是無害的，而POST會再次提交請求。

GET產生的URL地址能夠被Bookmark，而POST不能夠。

GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。

GET請求只能進行url編碼，而POST支持多種編碼方式。

GET請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留。

GET請求在URL中傳送的參數是有長度限制的，而POST麼有。

對參數的數據類型，GET只接受ASCII字符，而POST沒有限制。

GET比POST更不安全，由於參數直接暴露在URL上，因此不能用來傳遞敏感信息。

GET參數經過URL傳遞，POST放在Request body中。

HTTP 和 TCP 有什麼關係

http是在tcp基礎上的請求響應式協議。 tcp爲傳輸層協議，http爲應用層協議

HTTP 1.0 和 HTTP 1.1 的差異

http1.1增長了以下功能

可擴展性（1.1增長了版本號，OPTIONS，Upgrade等） 緩存強化（cache相關） 帶寬優化（文件斷點續傳，range相關） 長鏈接（keep-alive相關） host頭 身份認證，狀態管理

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鏈接不是同一個意思。 但實際上如今的HTTP支持keepalive等模式，支持單個鏈接處理多個請求應答。

有沒有保持長鏈接的 HTTP

HTTP1.1及更新的HTTP協議都支持keepalive長鏈接，甚至http2還支持服務端向客戶端推送數據

TCP 中客戶端發送 SYN 後客戶端和服務器分別處在什麼狀態

客戶端SYN_SENT，服務端則接收到SYN併發出ACK後轉爲SYN_RECV

服務器調用 send 後返回發送數據大小，是否能夠認爲客戶端已收到？如何確保客戶端收到數據

send返回發送數據大小後，說明數據已經到達或到達客戶端內核緩存，但並不能代表客戶端的進程已經拿到數據。若是須要確認對方客戶端進程收到，則須要與該進程在應用層實現相應的確認機制

304 狀態碼的意義？在 HTTP 協議中的實現

304校驗緩存：瀏覽器端cache的信息發送到服務器校驗，若是服務器認爲cache依然有效，則返回304，瀏覽器能夠繼續使用該cache

如何判斷服務器文件是否已修改？知道瀏覽器緩存的文件與服務器文件不一致？在 HTTP 中哪一個字段（TODO））

304校驗時，客戶端發送條件請求，帶If-Modified-Since頭，值爲服務器上次返回的Last-Modified頭中的時間，還會帶If-None-Match頭，值爲服務器上次返回的ETag響應頭的值 A 類地址和 B 類地址的區別

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程