計算機網路100問

已完成：協議模型（1-4）、應用層（5-35）、傳輸層（36-65），
待完成: 網路層、資料鏈路層
計算機網路知識點復習總結，持續更新中，，，
時間有限，可能存在部分紕漏和理解不當，歡迎指正交流，

計算機網路模型

1、五層因特網協議堆疊和七層OSI（Open System Interconnections）參考模型分別是什么？

5層：應用層、傳輸層、網路層、資料鏈路層、物理層
7層：應用層、表示層、會話層、傳輸層、網路層、資料鏈路層、物理層

2、為什么考慮分層的架構，有什么優勢和缺陷？

分層優勢

協議分層具有概念化和結構化的優點，分層提供了一種結構化方式來討論系統組件，模塊化使更新系統組件更為容易，

分層缺陷

分層的一個潛在缺點是一層可能冗余較低層的功能，例如，許多協議堆疊在基于每段鏈路和基于端到端兩種情況下，都提供了差錯恢復，第二種潛在的缺點是某層的功能可能需要僅在其他某層才出現的資訊（如時間戳值），這違反了層次分離的目標，

3、每一層的功能和作用分別是什么？每一層的傳輸資料型別是什么？

1. 應用層（資料）：確定兩個通信端點上的行程之間通信的性質以滿足用戶需要以及提供網路與用戶應用
2. 表示層（資料）：主要解決擁護資訊的語法表示問題，如加密解密
3. 會話層（資料）：提供包括訪問驗證和會話管理在內的建立和維護應用之間通信的機制，如服務器驗證用戶登錄便是由會話層完成的
4. 傳輸層（段）：提供應用行程之間的邏輯通信，實作網路不同主機上用戶行程之間的資料通信，可靠與不可靠的傳輸，傳輸層的錯誤檢測，流量控制等
5. 網路層（包）：提供主機之間的邏輯通信，提供邏輯地址（IP）、選路，資料從源端到目的端的傳輸
6. 資料鏈路層（幀）：將上層資料封裝成幀，用 MAC 地址訪問媒介，錯誤檢測與修正
7. 物理層（位元流）：設備之間位元流的傳輸，物理介面，電氣特性等

4、每一層使用哪些資料交換設備？

1. 網關：應用層、傳輸層（網關在傳輸層上以實作網路互連，是最復雜的網路互連設備，僅用于兩個高層協議不同的網路互連，網關的結構也和路由器類似，不同的是互連層，網關既可以用于廣域網互連，也可以用于局域網互連）
2. 路由器：網路層（路由選擇、存盤轉發）
3. 交換機：資料鏈路層、網路層（識別資料包中的 MAC 地址資訊，根據 MAC 地址進行轉發，并將這些 MAC 地址與對應的埠記錄在自己內部的一個地址表中）
4. 網橋：資料鏈路層（將兩個 LAN 連起來，根據 MAC 地址來轉發幀）
5. 集線器（Hub）：物理層（純硬體設備，主要用來連接計算機等網路終端
6. 中繼器：物理層（在位元級別對網路信號進行再生和重定時，從而使得它們能夠在網路上傳輸更長的距離）

應用層

5、主流的應用程式體系結構是哪些？他們的優缺點是什么？

C/S模式（客戶機/服務器）、P2P模式（對等方）、混合模式，

6、同一主機下和不同主機下的行程間是如何通信的？

同一主機下的行程間通信由作業系統決定，
不同的主機下的行程間通信通過訊息/報文交換完成，

7、什么是套接字socket?套接字是用來干什么的？

套接字是個API，是應用程式和網路的介面，行程可類比于一座房子，而它的套接字可以類比于它的門，當一個行程想向位于另外一臺主機上的另一個行程發送報文時，它把報文推出該門，

8、行程如何尋址？

主機地址（ip）+目的主機中指定接收行程的識別符號(埠號)

9、應用層協議定義了哪些東西？

1.交換的報文的型別：請求報文或相應報文
2.報文型別的語法，每個欄位是如何描述的
3.欄位的語意
4.確定一個行程何時以及如何發送報文，以及報文的相應規則

10、web應用程式的應用層協議是什么？什么是無狀態協議？

HTTP:超文本傳輸協議，所謂的無狀態協議是指服務器向客戶發送被請求的檔案，而不存盤任何關于該客戶的狀態資訊，HTTP協議就是無狀態協議，web應用利用cookie技術作為補充，彌補了HTTP協議無狀態帶來的可能缺陷，

11、什么是URL？格式是什么樣的？

URL：統一資源定位器，用于web頁面中物件的尋址，參考對應的物件，
一個web頁面由多個物件組成，包括一個html基本檔案和參考物件，參考物件用URL地址標識，
URL格式：協議://主機名/路徑名（http://www.baidu.com/documents）(這里涉及到DNS決議域名和主機名)

12、什么是持續連接和非持續連接？概念前提是什么？優缺點分別是什么？http協議采用哪種連接方式？

考慮每個請求/回應是經過一個獨立的TCP連接發送，還是所有的請求／回應經過相同的TCP連接發送，
前者為非持續連接（串行/并行），后者是持續連接（帶流水/不帶流水），
前提：C/S模式，TCP？？？
HTTP協議既可以使用持續連接也可以使用非持續連接，默認情況下使用帶流水線的持續連接，
帶流水線的持續連接：http客戶機遇到一個物件參考就發送一個請求，而不用等到前一個請求回應后再發送，

13、http報文型別及相應的報文格式

http請求報文格式:URL只包含路徑名，主機名在首部行中hosts

http回應報文格式

14、http請求報文常用方法有哪些？分別是什么作用？

HTTP1.0:GET、POST、HEAD
HTTP1.1:GET、POST、HEAD、PUT、DELETE
GET:請求物件
POST:上傳表單，一般放在物體體
HEAD:發送請求但不回傳請求物件，常用于除錯跟蹤
PUT:允許用戶上傳物件到服務器
DELETE:允許用戶洗掉服務器的某些物件

15、GET請求和POST請求的區別？

1.第一點區別：HTTP報文層面，GET將請求資訊放到URL，請求資訊與URL之間使用問號隔開，請求資訊格式是鍵值對的形式，POST將請求資訊放在報文體中，獲取請求資訊必須決議報文，GET請求是放在URL中的，URL本身是沒有長度限制的，但是瀏覽器是有長度限制的，會對URL進行長度限制，POST是將請求資訊放到報文體中的，所以對URL是沒有長度限制的，
2.第二點區別：資料庫層面，GET符合冪等性（對資料庫的一次操作或者多次操作的結果是一致的，則認為符合冪等性）和安全性（對資料庫的操作沒有改變資料庫的資料，則認為符合安全性的，GET操作是做查詢操作的，因此不會改變資料庫里面的資料），POST不符合（POST請求既不冪等也不安全，POST會向資料庫中提交資料，所以會改變資料庫里面的資料，POST每次獲取到的結果都有可能不一樣的，因為POST請求是作用在上一級的URL上面的，每一次請求都會添加新資源），
3.第三點區別：GET請求可以被快取（可以保存到瀏覽器的瀏覽記錄中），被存盤（GET請求URL可以被保存為瀏覽器書簽），但是POST不行，

16、http回應報文常見狀態碼和相關短語有哪些？分別什么含義？

HTTP狀態碼

1xx，指示資訊，表示請求已接收，繼續處理，
2xx，成功，表示請求已被成功接收、理解、接受，
3xx，重定向，要完成請求必須進行更進一步的操作，
4xx，客戶端錯誤，請求有語法錯誤或者請求無法實作，
5xx，服務器端錯誤，服務器未能實作合法的請求，

HTTP相關短語

200 OK:請求成功，資訊回傳在回應報文中
301 Moved Permanently:請求的物件被永久轉移，新的URL定義在回應報文的首部行Location中
400 Bad Request:通用差錯代碼，表示請求不能被服務器回應
401 Unauthorized:請求未經授權
403 Forbidden:服務器收到請求但是拒絕服務
404 Not Found:請求的檔案不在服務器上
500 Internal Server Error:服務器發生不可預期的錯誤
503 Server Unaviable:服務器當前不能處理客戶機請求
505 HTTP Version Not Supported:服務器不支持請求報文使用的http協議版本

17、簡述http請求回應的流程步驟，

1.客戶端連接到web服務器，一個http客戶端通常是瀏覽器與web服務器的http埠，默認埠號是80，建立一個tcp套接字連接，
2.然后發送http請求，即通過tcp套接字，客戶端向web服務器發送一個文本的請求報文，
1.然后服務器接受到客戶端的請求并回傳HTTP回應，web服務器決議該請求定位請求資源，服務器將資源副本寫到tcp套接字由客戶端讀取，
3.然后釋放TCP連接，若連接模式是CLOSE，則服務器主動關閉tcp連接，客戶端被動關閉tcp連接，釋放tcp連接，若連接模式是keep alive，咋該連接會保持一段時間，在該時間內可以繼續接受請求，
4.然后客戶端瀏覽器決議HTML內容，并進行決議，客戶端瀏覽器首先決議狀態行，查看表名請求是否成功的狀態代碼，然后決議每一個回應頭，回應頭告知以下若干位元組的HTML檔案和檔案的字符集，客戶端瀏覽器讀取回應資料HTML，根據html語法對其進行格式化，并在瀏覽器視窗中進行解釋，

18、什么是cookie?其四大組件是什么？

cookie內容

cookie技術允許站點對用戶進行跟蹤，因為HTTP是無狀態的，意味著每次訪問有登錄頁面的需求的時候，都要輸入賬號和密碼，Cookie技術是客戶端的解決方案，是由服務器發送給客戶端的特殊資訊，以文本的形式存放在客戶端，客戶端每次向服務器發送請求的時候都會帶上這些特殊資訊，比如當客戶使用瀏覽器訪問支持Cookie的網站的時候，需要輸入賬號和密碼提到到服務器，服務器向客戶端回應超文本的同時將個人資訊回傳，個人資訊不是存放在回應體http body中，而是保存到HTTP回應頭http header中的，當客戶端接收服務器的回應以后，瀏覽器將這些資訊存放到統一位置，客戶端再次請求的時候，會把Cookie發送到服務器中，Cookie資訊存放到http回應頭中，服務器接收到客戶端瀏覽器的請求以后，會分析存放在請求頭中的Cookie資訊，得到客戶端特有的資訊，從而動態生成與該客戶端相對應的內容，

cookie技術四大組件

1.在HTTP回應報文中的一個cookie首部行:set-cookie欄位
2.在HTTP請求報文中的一個cookie首部行：cookie欄位
3.在用戶端系統中保留有一個cookie檔案，并由用戶的瀏覽器進行管理
4.位于Web站點的一個后端資料庫

19、簡述cookie的設定和發送流程，

Cookie的設定以及發送程序，第一步，客戶端發送Http Requert請求到服務器，第二步，服務器端發送Http Response和設定Cookie頭部到客戶端，第三步，客戶端Http Request和Cookie頭部請求到服務器端，第四步，服務器端發送一個Http Response請求到客戶端，

20、什么是Session?Session怎么利用cookie?

Session概念

由于HTTP協議是無狀態的協議，所以服務端需要記錄用戶的狀態時，就需要用某種機制來識具體的用戶，這個機制就是Session.典型的場景比如購物車，當你點擊下單按鈕時，由于HTTP協議無狀態，所以并不知道是哪個用戶操作的，所以服務端要為特定的用戶創建了特定的Session，用用于標識這個用戶，并且跟蹤用戶，這樣才知道購物車里面有幾本書，這個Session是保存在服務端的，有一個唯一標識，在服務端保存Session的方法很多，記憶體、資料庫、檔案都有，集群的時候也要考慮Session的轉移，在大型的網站，一般會有專門的Session服務器集群，用來保存用戶會話，這個時候 Session 資訊都是放在記憶體的，使用一些快取服務比如Memcached之類的來放 Session，

session與cookie

思考一下服務端如何識別特定的客戶？這個時候Cookie就登場了，每次HTTP請求的時候，客戶端都會發送相應的Cookie資訊到服務端，實際上大多數的應用都是用 Cookie 來實作Session跟蹤的，第一次創建Session的時候，服務端會在HTTP協議中告訴客戶端，需要在 Cookie 里面記錄一個Session ID，以后每次請求把這個會話ID發送到服務器，我就知道你是誰了，有人問，如果客戶端的瀏覽器禁用了 Cookie 怎么辦？一般這種情況下，會使用一種叫做URL重寫的技術來進行會話跟蹤，即每次HTTP互動，URL后面都會被附加上一個諸如 sid=xxxxx 這樣的引數，服務端據此來識別用戶，

21、cookie和session有什么區別？簡述兩者兩者典型場景，

兩者都是常用的會話跟蹤技術，
1.cookie資料存放在客戶的瀏覽器上，session資料放在服務器上，
2.cookie不是很安全，別人可以分析存放在本地的cookie并進行cookie欺騙，考慮到安全應當使用session，
3.session會在一定時間內保存在服務器上，當訪問增多，會比較占用你服務器的性能，考慮到減輕服務器性能方面，應當使用cookie，

典型場景:登錄網站，今輸入用戶名密碼登錄了，第二天再打開很多情況下就直接打開了，這個時候用到的一個機制就是cookie，session一個場景是購物車，添加了商品之后客戶端處可以知道添加了哪些商品，而服務器端如何判別呢，所以也需要存盤一些資訊就用到了session，

22、什么是web快取器？如何判斷快取的物件是否是最新的？

代理服務器，能夠代表初始服務器滿足http請求的網路物體，客戶機請求先發送到代理服務器，代理服務器有請求內容直接回應，沒有繼續向上發送請求到初始服務器，能夠做到快速回應，減少請求的回應時間，但是存在需要解決快取資料新舊的問題，

條件GET方法:快取服務器發送使用GET方法發送請求報文給初始服務器，并在報文首部行中包含“If-Modified-Since”欄位，

23、什么是socket?

Socket是應用層與TCP/IP協議族通信的中間軟體抽象層，它是一組介面，在設計模式中，Socket其實就是一個門面模式，它把復雜的TCP/IP協議族隱藏在Socket介面后面，對用戶來說，一組簡單的介面就是全部，讓Socket去組織資料，以符合指定的協議，
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-8kfPF2II-1612014040638)(.\socket.jpg)]

24、什么是HTTPS？它和HTTP有什么關系和區別？

HTTPS（Hyper Text Transfer Protocol Secure）是超文本傳輸安全協議，HTTPS是一種以計算機網路安全通信為目的的傳輸協議，HTTP是包含了ip、tcp、http，而HTTPS比HTTP新增了SSL（SSL3.0后改名為TLS）（具有保護交換資料隱私，以及完整性，提供對網上服務器身份認證的功能，是安全版的http），
SSL(Securiy Sockets Layer，安全套接層)，為網路通信提供安全以及資料完整性的一種安全協議，SSL位于TCP與各應用層之間，是作業系統對外的API，SSL3.0以后更名為TLS，采用身份驗證和資料加密保證網路通信的安全和資料的完整性，

兩者區別

1.HTTPS需要到CA申請證書，HTTP不需要，
2.HTTPS（Hyper Text Transfer Protocol Secure）是超文本加密傳輸協議，具有安全性的SSL加密傳輸協議，是密文傳輸，HTTP（Hyper Text Transfer Protocol）是超文本傳輸協議，是明文傳輸，
3.連接方式的不同，埠的不同，HTTPS默認使用的埠是443埠，HTTP默認使用的埠是80埠，
4.HTTPS=HTTP+加密+認證+完整性保護，SSL是有狀態的，而HTTP連接是無狀態的，

25、簡述HTTPS的握手流程，

Https采用了證書和加密手段的方式保證資料的安全性，Https資料傳輸流程，Https在資料傳輸之前，會與網站服務器和web瀏覽器進行一次握手，在握手的時候確認雙方的加密密碼資訊，
具體流程如下所示:

1.web瀏覽器將支持的加密演算法資訊發送給網站服務器，
2.服務器選擇一套瀏覽器支持的加密演算法，將驗證身份的資訊以證書的形式回發瀏覽器，
3.瀏覽器收到證書以后驗證證書的合法性，如果證書受到瀏覽器信任，在瀏覽器地址欄有標志顯示，否則顯示不受信的標識，當證書受信以后，web瀏覽器隨機生成一串密碼，并使用證書中的公鑰加密，之后使用約定好的hash演算法握手訊息b并生成亂數對訊息進行加密，并將之前生成的資訊回發給服務器，
4.服務器接收到web瀏覽器發送的訊息以后，服務器使用私鑰解密資訊確認密碼，然后通過密碼解密web瀏覽器發送過來的握手資訊，并驗證哈希是否和web瀏覽器一致，加密新的握手回應訊息回發瀏覽器，
5.web瀏覽器解密服務器經過哈希演算法加密的握手回應訊息，并對訊息進行驗真，如果和服務器發送過來的訊息一致，則此握手程序結束以后，服務器和瀏覽器會使用之前瀏覽器生成的隨機密碼和對稱密碼進行加密，然后交換資料，

26、什么是DNS？它的名稱空間是怎么樣的（域名命名規范）？

DNS（Domain Name System）能進行主機名到IP地址轉換的目錄服務，此外還提供主機服務器別名、負載均衡(一個DNS名稱可以對應多個IP地址)等功能服務，該系統由分層的DNS服務器實作的分布式資料庫（根DNS服務器、頂級域DNS服務器（常見三類：組織域、國家域、反向域in-addr.arpa）、權威DNS服務器、本地DNS服務器（一般默認不屬于層次結構的一層，但至關重要））；一個使得主機能夠查詢分布式資料庫的應用層協議，DNS協議運行在UDP之上，使用53號埠，

名稱空間：完全限定域名（FQDN）主機名＋域名
(大家一般默認主機名為www的設備為自己的服務器:www.baidu.com)
(子域名申請后，可以在子域名下自定義網路層次：www.bbs.xidian.edu.cn)

27、簡述DNS決議原理和程序，

靜態決議：把經常訪問的IP存盤在本地，通過訪問本地檔案獲取回應的IP地址，稱之為靜態決議，比如：Linux作業系統會將部分主機名和IP映射存盤在靜態決議檔案中/etc/hosts，
動態決議：DNS決議，
1.客戶端拿著域名，請求DNS給查詢出ip:正向決議（一般主機想本地DNS服務器迭代查詢,本地DNS服務器向其他層級DNS服務器遞回查詢）
2.客戶端拿著ip，請求DNS給查詢出對應的全稱域名:逆向決議（具體怎么做的？）

迭代查詢和遞回查詢，（本地 ->root ->TLD ->權威）
如果考慮DNS快取，本地服務器可以快取TLD域名服務器的IP地址,在查詢時直接訪問TLD域名服務器，而不用通過根域名服務器再查詢TLD域名服務器的IP，
一般情況下，DNS決議先訪問瀏覽器快取、其次查看本地hosts檔案，再訪問路由快取查詢，最后跑向DNS服務器，

28、簡述DNS快取，

DNS快取即某DNS服務器在接收到某一主機名和IP地址的映射組時，會將該映射存盤在本地，便于客戶機的查詢，提高回應速度，由于，主機名和IP地址的映射并不是永久性的，所以DNS服務器往往兩天會丟棄快取的映射資訊，

29、簡述FTP概念，

FTP（File Transfer Protocol，檔案傳輸協議），作為網路共享檔案的傳輸協議，在網路應用軟體中具有廣泛的應用，FTP的目標是提高檔案的共享性和可靠高效地傳送資料，運行在TCP協議20（傳輸資料）、21（傳輸控制資訊）埠上，但是，是否使用20作為傳輸資料的埠與FTP使用的傳輸模式有關，如果采用主動模式，那么資料傳輸埠就是20；如果采用被動模式，則具體最終使用哪個埠要服務器端和客戶端協商決定，

30、FTP作業模式分別是哪兩種？

主動方式:PORT方式

主動模式下，客戶端隨機打開一個N(N>1024)埠向服務器的命令埠 P，即 21 埠，發起連接，同時開放N +1 埠監聽，并向服務器發出 “port N+1” （PORT h1,h2,h3,h4,p1,p2）命令，由服務器從它自己的資料埠 (20) 主動連接到客戶端指定的資料埠 (N+1)，
FTP 的客戶端只是告訴服務器自己的埠號，讓服務器來連接客戶端指定的埠，對于客戶端的防火墻來說，這是從外部到內部的連接，可能會被阻塞，

被動方式:PASV方式

被動方式下，命令連接和資料連接都由客戶端發起，這樣就解決了從服務器到客戶端的資料埠的連接被防火墻過濾的問題，被動模式下，當開啟一個 FTP 連接時，客戶端打開兩個任意的本地埠 (N > 1024 和 N+1) ，
第一個埠連接服務器的 21 埠，提交 PASV 命令，然后，服務器會開啟一個任意的埠 (P > 1024 )，回傳如“227 entering passive mode (127,0,0,1,4,18)”， 它回傳了 227 開頭的資訊，在括號中有以逗號隔開的六個數字，前四個指服務器的地址，最后兩個，將倒數第二個乘 256 再加上最后一個數字，這就是 FTP 服務器開放的用來進行資料傳輸的埠，如得到 227 entering passive mode (h1,h2,h3,h4,p1,p2)，那么埠號是 p1*256+p2，ip 地址為h1.h2.h3.h4，這意味著在服務器上有一個埠被開放，客戶端收到命令取得埠號之后, 會通過 N+1 號埠連接服務器的埠 P，然后在兩個埠之間進行資料傳輸，

兩種模式的差異

由于防火墻機制，主動模式不利于客戶端管理，被動模式不利于服務端管理，
主動情況下服務端資料端主動鏈接客戶端可能遭到客戶端防火墻攔截，
被動情況下客戶端主動訪問服務端資料埠可能遭到服務端防火墻攔截，

31、FTP各種指令和回應碼，

32、簡述FTP斷點續傳，

其實FTP斷點續傳的原理很簡單，可分為斷點下載和斷點上傳，
客戶端的實作步驟如下：
一、下載：

1、向服務器發送“REST + 本地檔案長度”命令，告訴服務器，客戶端要斷點下載了，這時服務器還不知道客戶端要下載哪個檔案； 要實作FTP的斷點續傳，FTP服務器必須支持REST指令，這條指令在FTP協議文本RFC959中就已經定義了，不過它不是FTP服務器必須支持的指令，一般,你可以在下載前使用REST 100命令進行實驗，如果服務器正常執行了這條命令，說明該服務器支持FTP斷點續傳，REST后面跟的數表示下載檔案的起始位置，而REST 0表示從檔案最開始處下載，REST命令本身并不執行下載功能，你仍需要使用RETR命令執行下載作業，
2、向服務器發送“RETR + 檔案名”命令，通知服務器要下載的檔案名，這時服務器開始定位檔案指標讀檔案并發送資料，
3、客戶端定位本地檔案指標（檔案末尾）；
4、兩端的準備作業都做完了以后，客戶端創建socket，以被動或非被動方式建立資料通道，回圈呼叫recv接收資料并追加入本地檔案；

二、上傳：

1、獲取服務器上和本地要上傳檔案的同名檔案大小；
2、向服務器發送“APPE ＋ 檔案名”，通知服務器，接下來從資料通道發送給你的資料要附加到這個檔案末尾，
3、定位本地檔案指標（和FTP上檔案大小相同的位置）
4、從檔案指標處讀資料并發送，

33、簡述匿名FTP，

匿名FTP，即匿名檔案傳輸協議，用于對遠程計算機的連接，這些計bai算機是作為匿名或客戶用戶進行連接的，以將公共檔案傳輸到用戶的本地計算機，使用FTP時必須首先登錄，在遠程主機上獲得相應的權限以后，方可上傳或下載檔案，也就是說，要想同哪一臺計算機傳送檔案，就必須具有哪一臺計算機的適當授權，匿名FTP就是為解決這個問題而產生的，互聯網中有很大一部分FTP服務器稱為“匿名”FTP服務器，這類服務器的目的是向公眾提供檔案拷貝服務，不要求用戶事先在該服務器進行登記注冊，也不用取得FTP服務器的授權，匿名檔案傳輸能夠使用戶與遠程主機建立連接并以匿名的身份從遠程主機上拷貝檔案，而不必是該遠程主機的注冊用戶，提供服務的機構在它的FTP服務器上建立一個公開賬戶（一般為anonymous），并賦予該賬戶訪問公共目錄的權限，

34、簡述DHCP，

動態主機配置協議，

35、埠號的基本引數，

埠號是16bit的資料，埠號范圍為0_{65535，其中0}1023是周知埠號，

傳輸層

36、簡述TCP和UDP概念及區別，

TCP：傳輸控制協議，TCP是面向字符流面向連接的協議，應用程式產生的全體資料與真正發送的單個IP資料報可能沒什么聯系，
UDP：用戶資料報協議，是一個簡單的面向資料報的無連接運輸層協議，行程的每個輸出操作都正好產生一個UDP資料報，并組裝成一份待發送的IP資料報，UDP協議只完成多路復用、多路分用和簡單的錯誤檢測的功能，

區別：

1. TCP面向連接，UDP面向無連接
2. TCP面向報文，UDP面向位元組流
3. TCP提供可靠傳輸服務（資料順序、正確性），UDP傳輸不可靠
4. TCP協議傳輸速度慢，UDP協議傳輸速度快
5. TCP協議對系統資源要求多（頭部開銷大），UDP協議要求少
6. TCP協議提供擁塞控制機制使得傳輸速率和時間不完全受應用程式控制，UDP沒有擁塞控制使得應用程式可以更好地控制發送時間和速率

337、在UDP上如何實作可靠的資料傳輸？

在應用層增加可靠性機制和應用特定的差錯恢復機制，增加了應用開發的難度，

38、簡述UDP報文欄位格式，

首部欄位+資料欄位，
UDP長度：包含欄位首部和欄位資料兩部分的總長度，
檢驗和：檢測UDP段在傳輸程序中是否發生錯誤，計算檢驗和時，除了UDP報文段（首部+資料欄位）以外還包括了偽首部，

發送方：UDP對報文段中的所有16位元字的和進行反碼運算, 求和時遇到的任何溢位都被回卷（回卷就是進位加到末位去），
接收方：同理計算校驗和，驗證計算結果和校驗和是否相等，不相等則說明檢測出錯誤，但是相等并不代表沒有錯誤，

39、什么是偽首部？偽首部有什么內容？為什么計算檢驗和時要增加偽首部?

偽首部只是虛擬的資料結構，在IP的分組頭中提取出來用于計算檢驗和，而不通過實際的傳輸，
所有偽首部包括：源IP地址，目的IP地址，0，協議號，UDP長度，
偽首部的增加其目的是讓UDP兩次檢查資料是否已經正確到達目的地（不僅需要報文內容正確還需要主機IP正確），可以確定目的IP地址是本機的（一次），作業系統將報文正確交付給了UDP（兩次），

40、什么是可靠傳輸協議（rdt）？有幾種常見的可靠傳輸協議及其潛在的缺陷？

rdt1.0：可靠信道上的可靠資料傳輸
rdt2.0：僅具有位元差錯信道的資料傳輸（差錯檢測、ACK/NAK機制、重傳機制）
rdt2.1：在rdt2.0基礎上，考慮ACK/NAK出錯情況（引入序列號，接收方根據序列號判斷是新分組還是重傳的分組）
rdt2.2：在rdt2.0基礎上，考慮沒有NAK，ACK出錯情況（接收方告知發送方最后一個被接收的分組序號）
rdt3.0：具有位元差錯和分組分組丟失的信道資料傳輸（在上述基礎上設定合理的等待時間）

41、為什么rdt停等協議性能并不高，有什么解決方案？

因為停等操作使得每一個分組發送出去都需要等待確認的時間，一輪RTT，導致效率并不高，可以采用流水線機制的rdt協議進行傳輸，不以停等方式運行，允許發送方發送多個分組而無須等待確認，以此增加效率，

42、采用流水線機制的可靠資料傳輸協議需要注意什么問題？

1.需要增加序列號的范圍
2.需要發送方有更大的分組快取空間
3.需要合適的差錯恢復機制：滑動視窗協議（GBD（回退N步）、SR（選擇重傳））

43、簡述回退N步(GBN)協議，

GBN協議中，發送方在發完一個資料幀后，連續發送若干個資料幀，即使在連續發送程序中收到了接收方發來的應答幀，也可以繼續發送，且發送方在每發送完一個資料幀時都要設定超時定時器(同一個定時器)，只要在所設定的超時時間內仍未收到確認幀，就要重發相應的資料幀，如：當發送方發送了N個幀后，若發現該N幀的前一個幀在計時器超時后仍未回傳其確認資訊，則該幀被判為出錯或丟失，此時發送方就不得不重新發送出錯幀及其后的N幀，
發送方僅使用一個定時器，它可被當作是最早的已發送但未被確認的分組所使用的定時器，如果收到一個ACK,但仍有已發送但未被確認的分組，則定時器被重新啟動，如果沒有已發送但未被確認的分組，停止該定時器，
接受幀只允許按順序接受幀ACK(n)，為了減少開銷，累計確認允許接收端在連續收到好幾個正確的確認幀后，只對最后一個資料幀發確認資訊，或者可以在自己有資料要發送時才將對以前正確收到的幀加以捎帶確認，這就是說，對某一資料幀的確認就表明該資料幀和這以前所有的資料幀均已正確無誤地收到了，(累計確認)
后退N幀協議的接受視窗為1，可以保證按序接受資料幀，若采用n個位元對幀編號，則其發送視窗的尺寸應滿足：1~2^{(n-1)，若發送視窗的尺寸大于2}(n-1)，則會造成接受方無法分辨新幀和舊幀，
缺點： 丟失的幀出錯，不僅要把丟失的幀重傳，還要把丟失的幀之后的幀也得重傳,傳輸效率降低了，

44、簡述選擇重傳（SR）協議，

SR協議是當接收方發現某幀出錯后，其后繼續送來的正確的幀雖然不能立即遞交給接收方的高層，但接收方可收下來，存放在一個緩沖區中，同時要求發送方重新傳送出錯的那一幀，一旦收到重新傳來的幀后，就可以原已存于緩沖區中的其余幀一并按正確的順序遞交高層，顯然，SR減少了浪費，但要求接收方有足夠大的緩沖區空間，

發送視窗大小+接收視窗大小<=2^(n)，

45、從滑動視窗角度比較停等、GBN、SR三種協議，

若從滑動視窗的觀點來統一看待停等、后退n及選擇重傳三種協議，它們的差別僅在于各自視窗尺寸的大小不同而已，停等：發送視窗= 1，接收視窗=1； 后退n協議：發送視窗>1，接收視窗=1；選擇重傳協議：發送視窗>1,接受視窗>1;

46、簡述TCP報文欄位格式，

序號：該報文段首位元組的位元組流編號，而不是段編號，
確認號：主機A填充進報文段的確認號是主機A期望從主機B收到的下一位元組的序號，也是采用累計確認的，（這點類似GBN）
標志欄位：8位，分別代表不同含義，
接收視窗：該欄位用于流量控制，用于指示接收方愿意接受的位元組數量，
緊急資料指標：指向緊急資料在報文段中結束的位置，
選項欄位：該欄位用于發送方與接收方協商最大報文段長度(MSS)時使用，

47、TCP中接收方如何處理亂序到達的報文段？

規范中并沒有規定，交給應用開發者決定，

48、TCP通過哪些方式保障資料傳輸的可靠性？

1.將應用資料被分割成 TCP 認為最適合發送的資料塊，
2.確認機制，發送報文后，等待確認，
3.重發機制，沒有收到確認，將重發資料段，
4.保持它首部和資料的校驗和， 確認資料的準確性，
5.排序，丟棄重復的，流量控制，

49、簡單介紹TCP三次握手原理，

1.第一次握手：建立連接時，客戶端發送SYN同步包(syn=x)（不能攜帶資料）到服務器，并進入SYN_SEND狀態即同步已發送，等待服務器確認，
2.第二次握手：服務器收到SYN包，必須確認客戶的SYN（ack=x+1），同時自己也發送一個SYN包（syn=y）（不能攜帶資料），即SYN+ACK包，此時服務器進入SYN_RECV狀態即同步已收到（即server收到SYN同步包以后，同意建立連接，向client回復一個ACK，由于tcp是全雙工傳輸的，server端同時向client端發送一個同步請求SYN，申請server端向client端建立連接，此時服務器進入SYN_RECV狀態），
3.第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=y+1)，此包發送完畢，客戶端和服務器進入ESTAB LISHED狀態即連接已建立，完成三次握手（即client收到server的ack后，client端的連接狀態變成了ESTABLISHED，同時client端向server端發送ack回應，回復server端的syn請求，server端收到client端的ack回應以后，server端的連接狀態變成了ESTABLISHED，此時，建立連接完成，雙方隨時可以進行資料傳輸），TCP的三次握手是為了建立雙向的連接，

50、為什么需要三次握手，而不是二次或者四次？

首先，需要明確的是，TCP握手建立連接，核心思想是在保證資料傳輸可靠和提高傳輸效率的兩個前提下，握手的目的是得到雙方的資料原點的序列號Sequence Number，
為了初始化Sequence Number的初始化值，通信的雙方要互相通知對方自己的初始化的Sequence Number值，即seq=x和seq=y，seq值要作為以后的資料通信的序號，以保證應用層接收到的資料不會因為網路上的傳輸問題而亂序，即Tcp會用這個序號進行拼接資料，因此在服務器回發它的Sequence Number即第二次握手之后，還需要客戶端發送確認報文給服務器，告訴服務器客戶端已經收到服務器的的初始化Sequence Number值，

不采用四次握手原因：可以將服務器對客戶端SYN同步包的回應回復ACK，和服務器發送給客戶端的SYN同步包合并起來，提高傳輸效率，
不采用兩次握手原因：兩次握手可能造成服務器和客戶端就服務器的初始序列值沒有達成一致，
TCP不會為沒有資料的ACK重傳！

51、首次握手的隱患SYN超時，問題起因分析，

Server服務器端收到Client客戶端發送的SYN，Server服務器端回復Client客戶端SYN-ACK的時候，如果此時Client客戶端掉線了，Server服務器端未收到Client客戶端的ACK確認，那么該連接就處于一個中間狀態，即未連接成功也未連接失敗狀態，此時Server服務器端不斷重試直至超時，Linux默認重試5次，重試間隔從1秒開始，每次翻倍，等待63秒鐘，tcp才會斷開連接，此時服務器可能遭受SYN Flood攻擊的風險，
針對SYN Flood攻擊風險的防護措施，比如惡意程式給服務器發送SYN報文，發送以后就進行了下線，然后服務器默認等待63秒才會斷開，攻擊者就會將服務器的SYN連接的佇列耗盡，讓正常的連接請求不能處理，Linux系統給出了一個方案，當SYN佇列滿后，通過tcp_syncookies引數回發SYN Cookie，TCP根據源地址埠，目標目的埠，時間戳生成一個特殊的Sequence Number即SYN Cookie回發給客戶端，如果是攻擊者是不會有回應的，若為正常連接則Client客戶端會回發服務器端SYN Cookie，直接建立連接，通過SYN Cookie創建的連接，即使現在SYN佇列滿后，本次連接請求不在佇列中，也可以創建連接，
如果建立連接后，Client客戶端出現故障怎么辦呢，其實TCP設定保活機制，在一段時間內，該時間被稱為保活時間keep alive time，在這段時間內，連接處于非活動狀態，開啟保活功能的一端將向對方發送保活探測報文，向對方發送保活探測報文，如果發送端未收到回應報文，如果在保活時間內即提前配置好的keep alive time則繼續發送，直到嘗試次數達到保活探測數仍未收到回應則中斷連接，對方直接將被確認為不可達，連接即被中斷，

52、簡單介紹TCP四次揮手原理，

1.第一次揮手：Client發送一個FIN，用來關閉Client到Server的資料傳送，Client進入FIN_WAIT_1狀態即中止等待1的狀態（即tcp的四次揮手是為了斷開連接，通信雙方都可以先發起斷開連接請求，這里以client作為先發起斷開連接的一端，通信中的client、server都是ESTABLISHED的狀態，client先發起來了關閉連接的請求，client端向server端發送了FIN包，表示client端沒有資料要發送了，client端進入了FIN_WAIT_1狀態了，），
2.第二次揮手：Server收到FIN后，發送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號），Server進入CLOSE_WAIT狀態即關閉等待狀態（即server端收到FIN包以后，向client發送ACK確認，然后server端進入了CLOSE_WAIT狀態，此時server屬于半關閉狀態，因為此時client不會再向server端發送資料了，server端向client端可能還要發送資料的，當server端資料發送完畢以后），
3.第三次揮手：Server發送一個FIN，用來關閉Server到Client的資料傳送，Server進入LAST_ACK狀態即最后確認狀態（即當server端資料發送完畢以后，server端向client端發送FIN包，表示server端也沒有資料要發送了，此時server進入了LAST_ACK狀態，等待client端的應答就可以關閉連接了，），
4.第四次揮手：Client收到FIN后，Client進入TIME_WAIT狀態即時間等待狀態，接著發送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態即關閉狀態，完成四次揮手（即client端收到server端的FIN后，回復ACK，進入TIME_WAIT狀態，切記TIME_WAIT狀態下，需要等待2倍的MSL最大報文段生存時間，來保證連接的可靠關閉，之后client進入CLOSE關閉狀態，server收到client的ack以后，直接進入close狀態，），

53、為什么會有TIME_WAIT狀態呢？

TIME-WAIT時間等待狀態到CLOSE關閉狀態，有一個超時設定，這個超時設定是2乘以MSL，為什么要等待這一段時間呢，TIME-WAIT狀態主要是要確保有足夠的時間讓對方收到ACK包，如果被動關閉的哪一方沒有收到ACK確認，就會觸發被動端重發FIN包（FINISH包）一來一去正好是2乘以MSL，也避免了新舊連接混淆，不讓這個連接和后面的連接混到一起，

54、為什么建立連接需要三次握手，而斷開連接需要四次揮手才能斷開連接呢？

全雙工的意思是允許資料在兩個方向上同時傳輸，即在同一時間服務器可以發送給客戶端，客戶端也可以發送資料給服務器，因為TCP是全雙工，發送方和接收方都需要FIN報文和ACK報文，也就是說發送方和接收方各自需要兩次揮手即可，只不過有一方是被動的，所以，看上去就變成了四次揮手，
無論是建立連接還是斷開連接，都是從兩個方向上進行，只不過建立連接的時候，server端的SYN和ACK包是合并為一次發送，而斷開連接的時候，兩個方向的資料發送的停止時間可能是不同的，所以無法合并FIN和ACK包，FIN和ACK是分開發送的，這就是建立連接的時候必須要三次握手，斷開連接的時候要四次揮手的原因，

55、簡述TCP同時打開流程，

兩端的狀態變化都是由CLOSED->SYN_SENT->SYN_RCVD->ESTABLISHED，

56、簡述TCP同時關閉流程，

兩端的狀態變化都是由ESTABLISHED->FIN_WAIT_1->CLOSING->TIME_WAIT->CLOSED，

57、簡述TCP半打開和半關閉流程，

半打開：
　　TCP的半開連接是指TCP連接的一端例外崩潰，或者在未通知對端的情況下關閉連接，這種情況下不可以正常收發資料，否則會產生RST(后面內容我們在介紹RST)，比如一個常見的情況是TCP連接的一端例外斷電，就會導致TCP的半開連接，如果沒有資料傳輸，對端就不會知道本端的例外而一直處于ESTABLISHED狀態(TCP有存活檢測機制，后面內容我們會進行介紹)，
　　另外從linux實作的角度來說，因為linux內部有個半連接佇列，TCP半開連接是指發送了TCP連接請求，等待對方應答的狀態，此時連接并沒有完全建立起來,雙方還無法進行通信互動的狀態，此時就稱為半連接，由于一個完整的TCP連接需要經過三次握手才能完成,這里把三次握手之前的連接都稱之為半打開連接，

半關閉：
　　TCP的半關連接是指TCP連接只有一方發送了FIN，另一方沒有發出FIN包，仍然可以在一個方向上正常發送資料，這種場景并不常見，一般來說Berkeley sockets API呼叫shutdown()介面時候就會進入半關閉狀態(呼叫常規的close()一般是期待完整的雙向關閉這個TCP連接)，shutdown()介面相當指示程式，本端已經沒有資料待發送，所以我發送一個FIN到對端，但是我仍然想要從對端接收資料，直到對端發送一個FIN指示關閉連接為止，如下圖所示，在紅色背景文本框標注的資料傳輸場景下就是TCP的半關連接，

58、RTT往返時間估計，

RTT定義：報文段的樣本RTT （表示為SampleRTT）就是從某報文段被發出（即交給IP）到對該報文段的確認被收到之間的時間量，大多數TCP的實作僅在某個時刻做一次SampleRTT測量，而不是為每個發送的報文段測量一個SampleRTT，
此外，TCP還維護EstimatedRTT和DevRTT兩個引數,重傳間隔的設定就依據這三個引數來設定，
SampleRTT的均值EstimatedRTT：
EstimatedRTT = （1 - a） ? EstimatedRTT + a ? SampleRTT
RTT偏差：
DevRTT = （1 -c） ? DevRTT +c ? | SampleRTT - EstimatedRTT |

59、TCP定時器超時時間間隔設定，

超時重傳定時器（RTO）時間間隔設定： 初始值建議設定為1s
Timeoutinterval = EstinMrtedRTT +4 ? DevRTT
實際中，TCP在Timeoutinterval的動態變化中還需要考慮流量和擁塞控制情況，并不一定完全按照上述估計，
超時間隔加倍：TCP每次重傳時都會將下一次的超時間隔設從EstimatedRTT為先前值的兩倍，而不是用DevRTT和EstinmatedRTT推算出,主要是用于規避網路擁塞的風險，

60、TCP是一個GBN協議還是一個SR協議？

都不是，更像是一個結合體，
TCP確認是累積式的，正確接收但失序的報文段是不會被接收方逐個確認的，這點類似于GBN**（但是GBN的ack=已確認的序號，而TCP的ack=期待接下來收到的序號（和GBN差1）），因此，發送方僅需維持已發送過但未被確認的位元組的最小序號和下一個要發送的位元組的序號，但是，TCP會將正確接收但失序的報文段快取起來**，這點類似于SR，TCP的選擇確認機制,它允許TCP接收方有選擇地確認失序報文段，而不是累積地確認最后一個正確接收的有序報文段，當將該機制與選擇重傳機制結合起來使用時(即跳過重傳那些已被接收方選擇性地確認過的報文段)，TCP看起來就很像SR協議，TCP每個報文段維護一個計時器用于超時重傳，這點類似于SR，

舉個栗子：

61、TCP連接使用的四個計時器分別是什么？有什么作用？

1.超時重傳計時器（60s）：當TCP發送報文段時，就創建該特定報文段的重傳計時器，
2.持續計時器（60s）：用于流量控制，在接收端發送接收視窗大小=0報文后，發送端在持續計時器超時后，發送探詢訊息試探接收視窗的大小，以此來避免接收端重新發送>0的視窗報文給發送方時出現報文丟失，造成雙方僵持等待的死鎖情況，
3.保活計時器（2h）：保活計時器用來防止兩個TCP之間的連續出現長時間的空閑，
4.時間等待計時器(2MSL)：當客戶端進入TIME-WAIT狀態的時候，鏈接還沒有釋放掉，必須等待2倍的MSL(最長報文段壽命)后，客戶端才能關閉連接，在時間等待期間，鏈接還處于一種過渡狀態，

62、簡述TCP流量控制機制，

所謂的流量控制就是讓發送方的發送速率不要太快，讓接收方來得及接收，由于雙方在通信的時候，發送方的速率與接收方的速率是不一定相等，如果發送方的發送速率太快，會導致接收方處理不過來，這時候接收方只能把處理不過來的資料存在快取區里（失序的資料包也會被存放在快取區里），如果快取區滿了發送方還在瘋狂著發送資料，接收方只能把收到的資料包丟掉，大量的丟包會極大著浪費網路資源，
利用滑動視窗機制可以很方便的在TCP連接上實作對發送方的流量控制，
**那怎么進行流量控制呢？**接收方每次收到資料包，可以在發送確定報文的時候，同時告訴發送方自己的快取區還剩余多少是空閑的，我們也把快取區的剩余大小稱之為接收視窗大小，發送方收到之后，便會調整自己的發送速率，也就是調整自己發送視窗的大小，當發送方收到接收視窗的大小為0時，發送方就會停止發送資料，防止出現大量丟包情況的發生，
那發送方何時再繼續發送資料呢? 當發送方收到接受視窗 win = 0 時，這時發送方停止發送報文，并且同時開啟一個定時器(持續計時器），每隔一段時間就發個測驗報文去詢問接收方，打聽是否可以繼續發送資料了，如果可以，接收方就告訴他此時接受視窗的大小；如果接受視窗大小還是為0，則發送方再次重繪啟動定時器，
那視窗大小怎么設定呢？

63、什么是AIMD？

AIMD（加法遞增，乘法遞減法則) 是TCP采用的擁塞控制法則，但是并不絕對公平，因為根據往返時間調整視窗的大小，這就造成接近主機的連接比遠離主機的連接獲得的帶寬多，

64、簡述TCP擁塞控制機制，

所謂擁塞控制就是防止過多的資料注入到網路中，這樣可以使網路中的路由器或鏈路不致過載，
TCP擁塞控制機制有兩個版本：TCP Tahoe和TCP Reno，兩者的差別在于是否采用快速恢復機制，

慢啟動:

當新建連接時，cwnd初始化為1個最大報文段(MSS)大小，發送端開始按照擁塞視窗大小發送資料，每當有一個報文段被確認，cwnd就增加1個MSS大小，這樣cwnd的值就隨著網路往返時間(RTT)呈指數級增長，事實上，慢啟動的速度一點也不慢，只是它的起點比較低一點而已，

擁塞避免:

從慢啟動可以看到，cwnd可以很快的增長上來，從而最大程度利用網路帶寬資源，但是cwnd不能一直這樣無限增長下去，一定需要某個限制，TCP使用了一個叫慢啟動門限(ssthresh)的變數，當cwnd超過該值后，慢啟動程序結束，進入擁塞避免階段，對于大多數TCP實作來說，ssthresh的值是65536(同樣以位元組計算)，擁塞避免的主要思想是加法增大，也就是cwnd的值不再指數級往上升，開始加法增加，此時當視窗中所有的報文段都被確認時，cwnd的大小加1，cwnd的值就隨著RTT開始線性增加，這樣就可以避免增長過快導致網路擁塞，慢慢的增加調整到網路的最佳值，

快速重傳:

TCP對每一個報文段都有一個定時器，稱為重傳定時器(RTO)，當RTO超時且還沒有得到資料確認，那么TCP就會對該報文段進行重傳，此時，發送端就認為網路處于擁塞狀態，
采用快速重傳的前提要求接收方在收到一個失序的報文段后就立即發出重復確認（為的是使發送方及早知道有報文段沒有到達對方）而不要等到自己發送資料時捎帶確認，快速重傳可以提升網路吞吐量，TCP在收到亂序到達包時就會立即發送ACK，TCP利用3個相同的ACK來判定資料包的丟失（重復確認）而不用等到計時器超時，此時，發送端就認為網路處于擁塞狀態，

快速恢復:

考慮到如果網路出現擁塞的話就不會收到好幾個重復的確認，所以發送方現在認為網路可能沒有出現擁塞，
Tahoe:在認為網路處于擁塞狀態之后，進行如下操作：（1）慢啟動門限設定為當前擁塞視窗大小的一半，（2）把擁塞視窗設定為1，（3）重新進入慢啟動狀態，
Reno:在認為網路處于擁塞狀態之后，進行如下操作：（1）慢啟動門限設定為當前擁塞視窗大小的一半，（2）把擁塞視窗設定為修改后的慢啟動門限值，（3）進入擁塞避免狀態，

TCP Tahoe版本示意圖

TCP Reno版本示意圖

65、簡述流量控制（滑動視窗rwnd）和擁塞控制（擁塞視窗cwnd）的相同點和區別，

同： 兩者的現象都是丟包，實作機制都是讓發送方發的慢一點，發的少一點，
異： 擁塞控制所要做的都有一個前提，就是網路能承受現有的網路負荷，流量控制往往指的是點對點通信量的控制，是個端到端的問題，流量控制所要做的就是控制發送端發送資料的速率，以便使接收端來得及接受，擁塞控制的丟包發生在路由器上，流量控制的丟包發生在接收端，

滑動視窗一般指接收視窗，接收器視窗是接收器可以獲取資料包的緩沖區，用于流量控制，而擁塞視窗用于擁塞控制，TCP真正的發送視窗=min(rwnd,cwnd)，

Quick and Quick! Salute!