1.TCP報(bào)頭格式 ? UDP報(bào)頭格式?
TCP報(bào)頭格式
UDP報(bào)頭格式
具體的各部分解釋看
TCP報(bào)頭的數(shù)據(jù)偏移有四位2進(jìn)制數(shù)（最大是1111），換成十進(jìn)制就是最大為15，很特殊的是其中每一位代表四個(gè)字節(jié)，也就是最多有15*4=60個(gè)字節(jié)。數(shù)據(jù)偏移量--------就是真正的數(shù)據(jù)在這個(gè)報(bào)文段開始的位置，也就是報(bào)文頭部的全部長度。
TCP檢驗(yàn)和計(jì)算過程： ??TCP首部校驗(yàn)和計(jì)算三部分：TCP首部+TCP數(shù)據(jù)+TCP偽首部。
UDP協(xié)議格式 - CSDN博客? TCP校驗(yàn)和和UDP幾乎一樣，就是UDP偽首部中8位傳輸層協(xié)議號(hào)是17而TCP是6
? 2.TCP/UDP區(qū)別（不僅是宏觀上的，最好能根據(jù)各自的機(jī)制講解清楚）
1、TCP面向連接（如打電話要先撥號(hào)建立連接）;UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接
2、TCP提供可靠的服務(wù)。也就是說，通過TCP連接傳送的數(shù)據(jù)，無差錯(cuò)，不丟失，不重復(fù)，且按序到達(dá);UDP盡最大努力交付，即不保證可靠交付；? Tcp通過校驗(yàn)和，重傳控制，序號(hào)標(biāo)識(shí)，滑動(dòng)窗口、確認(rèn)應(yīng)答實(shí)現(xiàn)可靠傳輸。如丟包時(shí)的重發(fā)控制，還可以對次序亂掉的分包進(jìn)行順序控制。
3、UDP具有較好的實(shí)時(shí)性，工作效率比TCP高，適用于對高速傳輸和實(shí)時(shí)性有較高的通信或廣播通信。
4.每一條TCP連接只能是點(diǎn)到點(diǎn)的;UDP支持一對一，一對多，多對一和多對多的交互通信
5、TCP對系統(tǒng)資源要求較多，UDP對系統(tǒng)資源要求較少。
具體參考區(qū)別，優(yōu)缺點(diǎn)參考TCP和UDP的區(qū)別和優(yōu)缺點(diǎn) - CSDN博客（里面還有TCP和UDP編程的不同）
?3. HTTP狀態(tài)碼（最好結(jié)合使用場景，比如在緩存命中時(shí)使用哪個(gè)） ??
HTTP狀態(tài)碼具體參考HTTP狀態(tài)碼 | 菜鳥教程
當(dāng)瀏覽者訪問一個(gè)網(wǎng)頁時(shí)，瀏覽者的瀏覽器會(huì)向網(wǎng)頁所在服務(wù)器發(fā)出請求。當(dāng)瀏覽器接收并顯示網(wǎng)頁前，此網(wǎng)頁所在的服務(wù)器會(huì)返回一個(gè)包含HTTP狀態(tài)碼的信息頭（server header）用以響應(yīng)瀏覽器的請求。
HTTP狀態(tài)碼的英文為HTTP Status Code。
下面是常見的HTTP狀態(tài)碼：
100 - 客戶端應(yīng)當(dāng)繼續(xù)發(fā)送請求（1** ? ? 1開頭的信息，服務(wù)器收到請求，需要請求者繼續(xù)執(zhí)行操作）
200 - 請求成功 ? ? ? ? ?? 201 - 請求已經(jīng)被實(shí)現(xiàn)，而且有一個(gè)新的資源已經(jīng)依據(jù)請求的需要而建立
?202 - ?服務(wù)器已接受請求，但尚未處理 ? ? ? ? ? ? ? (2**成功，操作被成功接收并處理)
301 - 資源（網(wǎng)頁等）被永久轉(zhuǎn)移到其它URL ； ?? 304：客戶端已經(jīng)執(zhí)行了GET，但文件未變化 ? ?
?(3**重定向，需要進(jìn)一步的操作以完成請求)
404 - 請求的資源（網(wǎng)頁等）不存在 ? ? ?? (4**客戶端錯(cuò)誤，請求包含語法錯(cuò)誤或無法完成請求)
500 - 內(nèi)部服務(wù)器錯(cuò)誤 ? ? ? ?? 503 - 服務(wù)器超時(shí) ? ? ? ? ? ? (5**服務(wù)器錯(cuò)誤，服務(wù)器在處理請求的過程中發(fā)生了錯(cuò)誤)
4.HTTP協(xié)議（一些報(bào)頭字段的作用，如cace-control、keep-alive）? ?
很詳細(xì)的教程HTTP 教程 | 菜鳥教程
HTTP 簡介
HTTP協(xié)議是Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫,是用于從萬維網(wǎng)（WWW:World Wide Web ）服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。HTTP是一個(gè)基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)（HTML 文件, 圖片文件, 查詢結(jié)果等）。
超文本：超文本是用超鏈接的方法，將各種不同空間的文字信息組織在一起的網(wǎng)狀文本
HTTP 工作原理
HTTP協(xié)議工作于客戶端-服務(wù)端架構(gòu)上，是一種無狀態(tài)協(xié)議。瀏覽器作為HTTP客戶端通過URL向HTTP服務(wù)端即WEB服務(wù)器發(fā)送所有請求。
Web服務(wù)器有：Apache服務(wù)器，IIS服務(wù)器（Internet Information Services）等。web服務(wù)器之iis，apache，tomcat三者之間的比較 - CSDN博客
Web服務(wù)器根據(jù)接收到的請求后，向客戶端發(fā)送響應(yīng)信息。
HTTP默認(rèn)端口號(hào)為80，但是你也可以改為8080或者其他端口。
HTTP頭信息解讀： ??/(ㄒoㄒ)/~~HTTP頭部
HTTP的頭域包括通用頭、請求頭、響應(yīng)頭和實(shí)體頭四個(gè)部分。每個(gè)頭域由一個(gè)域名，冒號(hào)（:）和域值三部分組成（說白了就是鍵值對）。
通用頭：是客戶端和服務(wù)器都可以使用的頭部，可以在客戶端、服務(wù)器和其他應(yīng)用程序之間提供一些非常有用的通用功能，如Date頭部。
請求頭：是請求報(bào)文特有的，它們向服務(wù)器提供了一些額外信息，比如客戶端希望接收什么類型的數(shù)據(jù)，如Accept頭部。
響應(yīng)頭：便于向客戶端提供信息，比如，客戶端在與哪種類型的服務(wù)器進(jìn)行交互，如Server頭部。
實(shí)體頭：指的是用于應(yīng)對實(shí)體主體部分的頭部，比如，可以用實(shí)體頭部來說明實(shí)體主體部分的數(shù)據(jù)類型，如Content-Type頭部。
（1）HTTP通用頭：（選了幾個(gè)記一下就好）
1）Cache-Control ：指定請求和響應(yīng)遵循的緩存機(jī)制（包括no-cache：指示請求或響應(yīng)消息不能緩存，no-store：緩存應(yīng)該盡快從存儲(chǔ)器中刪除文檔的所有痕跡等）
2）Connection ：Connection表示是否需要持久連接（Close：告訴WEB服務(wù)器或者代理服務(wù)器，在完成本次請求的響應(yīng)后，斷開連接，不要等待本次連接的后續(xù)請求了；? Keepalive：告訴WEB服務(wù)器或者代理服務(wù)器，在完成本次請求的響應(yīng)后，保持連接，等待本次連接的后續(xù)請求； Keep-Alive：如果瀏覽器請求保持連接，則該頭部表明希望 WEB 服務(wù)器保持連接多長時(shí)間（秒），如Keep-Alive：300）
（2）HTTP請求頭：
?1）Host：請求資源所在的服務(wù)器域名（對于虛擬主機(jī)來說）以及（可選的）服務(wù)器監(jiān)聽的TCP端口號(hào)。如果所請求的端口是對應(yīng)的服務(wù)的標(biāo)準(zhǔn)端口（80），則端口號(hào)可以省略。（例如 ? ? Host: www.itbilu.com:80；? Host: www.itbilu.com；Host: developer.cdn.mozilla.net）。Host請求頭實(shí)際上就是為了讓客戶端能辨別這個(gè)請求到底是來自同一個(gè)IP地址（對應(yīng)一個(gè)虛擬機(jī)）對應(yīng)的多個(gè)域名中的哪一個(gè)。
?2）Accept ：告訴WEB服務(wù)器自己接受什么介質(zhì)類型，(例如：Accept:text/plain ，相當(dāng)于告訴服務(wù)端，客戶端能夠接受的響應(yīng)類型僅為純文本數(shù)據(jù)）
3）Cookie:? 客戶端的Cookie就是通過這個(gè)報(bào)文頭屬性傳給服務(wù)端的。( 服務(wù)端是怎么知道客戶端的多個(gè)請求是隸屬于一個(gè)Session呢？原來就是通過HTTP請求報(bào)文頭的Cookie屬性的jsessionid的值關(guān)聯(lián)起來的 )
（3）HTTP響應(yīng)頭：
1）Age：響應(yīng)對象在代理緩存中存在的時(shí)間，以秒為單位（Age: 12）
2）ETag: 資源的匹配信息，ETag是一個(gè)可以與Web資源關(guān)聯(lián)的記號(hào)（token）。ETag一般不以明文形式相應(yīng)給客戶端。在資源的各個(gè)生命周期中，它都具有不同的值，用于標(biāo)識(shí)出資源的狀態(tài)。當(dāng)資源發(fā)生變更時(shí)，如果其頭信息中一個(gè)或者多個(gè)發(fā)生變化，或者消息實(shí)體發(fā)生變化，那么ETag也隨之發(fā)生變化
（4）HTTP實(shí)體頭：
1）Allow：服務(wù)器支持哪些請求方法（如GET、POST等）。 ? ?
2）Content-Encoding: gzip? ； ? ?實(shí)體主體適用的編碼方式
3）Content-Language: zh-cn；? 實(shí)體的自然語言?
4）Content-Length:80 ? ；? 實(shí)體主體的大?。ㄗ止?jié)）
HTTP1.1 和 HTTP1.0區(qū)別：
1，HTTP/1.0協(xié)議使用非持久連接 而?HTTP/1.1協(xié)議使用持久連接
HTTP/1.0協(xié)議使用非持久連接,即在非持久連接下,一個(gè)tcp連接只傳輸一個(gè)Web對象,；HTTP/1.1默認(rèn)使用持久連接(然而,HTTP/1.1協(xié)議的客戶機(jī)和服務(wù)器可以配置成使用非持久連接)。在持久連接下,不必為每個(gè)Web對象的傳送建立一個(gè)新的連接,一個(gè)連接中可以傳輸多個(gè)對象! ??HTTP 1.1的持續(xù)連接，需要增加新的請求頭來幫助實(shí)現(xiàn)，例如，Connection請求頭的值為Keep-Alive時(shí)，客戶端通知服務(wù)器返回本次請求結(jié)果后保持連接；Connection請求頭的值為close時(shí)，客戶端通知服務(wù)器返回本次請求結(jié)果后關(guān)閉連接。
2. ? HTTP 1.0不支持Host請求頭字段，而HTTP/1.1協(xié)議增加Host請求頭字段
HTTP 1.0不支持Host請求頭字段，WEB瀏覽器無法使用主機(jī)頭名來明確表示要訪問服務(wù)器上的哪個(gè)WEB站點(diǎn)，這樣就無法使用WEB服務(wù)器在同一個(gè)IP地址和端口號(hào)上配置多個(gè)虛擬WEB站點(diǎn)。在HTTP 1.1中增加Host請求頭字段后，WEB瀏覽器可以使用主機(jī)頭名來明確表示要訪問服務(wù)器上的哪個(gè)WEB站點(diǎn)，這才實(shí)現(xiàn)了在一臺(tái)WEB服務(wù)器上可以在同一個(gè)IP地址和端口號(hào)上使用不同的主機(jī)名來創(chuàng)建多個(gè)虛擬WEB站點(diǎn)。
3.HTTP 1.1還提供了與身份認(rèn)證、狀態(tài)管理和Cache緩存等機(jī)制相關(guān)的請求頭和響應(yīng)頭。
5.? OSI協(xié)議、TCP/IP協(xié)議以及每層對應(yīng)的協(xié)議 ??
OSI，TCP/IP，五層協(xié)議的體系結(jié)構(gòu)，以及各層協(xié)議
OSI分層 （7層）：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會(huì)話層、表示層、應(yīng)用層。
TCP/IP四層模型（4層）：網(wǎng)絡(luò)接口層、 網(wǎng)絡(luò)層、運(yùn)輸層、 應(yīng)用層。
TCP/IP五層體系結(jié)構(gòu) （5層）：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、運(yùn)輸層、 應(yīng)用層。
每一層的協(xié)議如下：
物理層：RJ45、CLOCK、IEEE802.3 ? ?（中繼器，集線器，網(wǎng)關(guān)）
數(shù)據(jù)鏈路：CSMA/CD、PPP（撥號(hào)上網(wǎng)基本都是用的PPP協(xié)議， PPP協(xié)議就是用戶計(jì)算機(jī)和ISP進(jìn)行通信時(shí)所使用的數(shù)據(jù)鏈路層協(xié)議）、ATM、Frame? Relay 、HDLC、VLAN、MAC ?（網(wǎng)橋，交換機(jī)）?網(wǎng)絡(luò)知 ? ? ? ? ? ? ?? 識(shí)總結(jié)二：物理層和鏈路層協(xié)議詳解 - CSDN博客 ? ? ? ?? ATM協(xié)議及ATM技術(shù)介紹 - CSDN博客 ? ?
（1）封裝成幀；
（2）透明傳輸：是不管傳的是什么，所采用的設(shè)備只是起一個(gè)通道作用，把要傳輸?shù)膬?nèi)容完好的傳到對方；
網(wǎng)絡(luò)層：IP、ICMP（因特網(wǎng)控制報(bào)文協(xié)議）、IGMP（因特網(wǎng)組管理協(xié)議），ARP（地址解析協(xié)議）、 ? ? ? ? ? ? ?? RARP、OSPF、IPX、RIP、IGRP （內(nèi)部網(wǎng)關(guān)路由協(xié)議） ? ? ? ?? 網(wǎng)絡(luò)層協(xié)議原理
ICMP：定義了網(wǎng)絡(luò)層控制和傳遞消息的功能，可以報(bào)告IP數(shù)據(jù)包傳送過程中發(fā)生的錯(cuò)誤，失敗等信息，提供網(wǎng)絡(luò)診斷功能。
傳輸層：TCP、UDP、SPX
會(huì)話層：NFS ( 網(wǎng)絡(luò)文件系統(tǒng)協(xié)議 )、SQL（結(jié)構(gòu)化查詢語言協(xié)議）、NETBIOS（網(wǎng)絡(luò)的基本輸入輸出 ? ? ? ? ? ? ?? 系統(tǒng)協(xié)議）、RPC (遠(yuǎn)程過程調(diào)用協(xié)議，它是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請求服務(wù)) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
表示層：JPEG（圖像壓縮標(biāo)準(zhǔn)協(xié)議）、MPEG（運(yùn)動(dòng)圖象專家組協(xié)議）、ASCII（ASCII碼通訊協(xié)議）
應(yīng)用層：FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS
深入理解FTP協(xié)議 - luoxn28 - 博客園
文件傳輸協(xié)議有基于TCP的FTP和 基于UDP的簡單文件傳輸協(xié)議TFTP，它們都是文件共享協(xié)議中的一大類，即復(fù)制整個(gè)文件，其特點(diǎn)是：若要存取一個(gè)文件，就必須先獲得一個(gè)本地的文件副本。如果要修改文件，只能對文件的副本進(jìn)行修改，然后再將修改后的文件傳回到原節(jié)點(diǎn)。
? ? ? ? ? ? ? 應(yīng)用層常用協(xié)議 - CSDN博客 ? ? ? ? ?? 應(yīng)用層協(xié)議 - 專注it - 博客園
（注釋：IP協(xié)議的功能：
（1）尋址和路由；（根據(jù)對方的IP地址，尋找最佳路徑傳輸信息）；
（2）傳遞服務(wù)：① 不可靠（IP協(xié)議只是盡自己最大努力去傳輸數(shù)據(jù)包），可靠性由上層協(xié)議提供（TCP協(xié)議）；② 無連接；（事先不建立會(huì)話）；
（3）數(shù)據(jù)包的分片和重組。IP協(xié)議及IP數(shù)據(jù)包詳解 - CSDN博客
每一層的作用如下：
物理層：該層包括物理連網(wǎng)媒介，如電纜連線連接器。物理層的協(xié)議產(chǎn)生并檢測電壓以便發(fā)送和接收攜帶數(shù)據(jù)的信號(hào)。
數(shù)據(jù)鏈路層：它控制網(wǎng)絡(luò)層與物理層之間的通信。它的主要功能是如何在不可靠的物理線路上進(jìn)行數(shù)據(jù)的可靠傳遞
網(wǎng)絡(luò)層：其主要功能是將網(wǎng)絡(luò)地址翻譯成對應(yīng)的物理地址，并決定如何將數(shù)據(jù)從發(fā)送方路由到接收方
傳輸層：傳輸協(xié)議同時(shí)進(jìn)行流量控制或是基于接收方可接收數(shù)據(jù)的快慢程度規(guī)定適當(dāng)?shù)陌l(fā)送速率。除此之外，傳輸層按照網(wǎng)絡(luò)能處理的最大尺寸將較長的數(shù)據(jù)包進(jìn)行強(qiáng)制分割
會(huì)話層：負(fù)責(zé)在網(wǎng)絡(luò)中的兩節(jié)點(diǎn)之間建立和維持通信。
表示層：在表示層，數(shù)據(jù)將按照網(wǎng)絡(luò)能理解的方案進(jìn)行格式化；如加密解密，轉(zhuǎn)換翻譯，壓縮解壓
應(yīng)用層：負(fù)責(zé)對軟件提供接口以使程序能使用網(wǎng)絡(luò)服務(wù)。
? 6.SESSION（會(huì)話）機(jī)制、cookie機(jī)制 ，session跨域問題
Cookie 和 Session機(jī)制詳解 - CSDN博客
會(huì)話跟蹤是Web程序中常用的技術(shù)，用來跟蹤用戶的整個(gè)會(huì)話。常用的會(huì)話跟蹤技術(shù)是Cookie與Session。Cookie通過在客戶端記錄信息確定用戶身份，Session通過在服務(wù)器端記錄信息確定用戶身份。
cookie機(jī)制 ：是客戶端的解決方案，Cookie就是由服務(wù)器發(fā)給客戶端的特殊信息，而這些信息以文本文件的方式存放在客戶端，然后客戶端每次向服務(wù)器發(fā)送請求的時(shí)候都會(huì)帶上這些特殊的信息。
Session機(jī)制：是另一種記錄客戶狀態(tài)的機(jī)制，不同的是Cookie保存在客戶端瀏覽器中，而Session保存在服務(wù)器上。客戶端瀏覽器訪問服務(wù)器的時(shí)候，服務(wù)器把客戶端信息以某種形式記錄在服務(wù)器上。客戶端瀏覽器再次訪問時(shí)只需要從該Session中查找該客戶的狀態(tài)就可以了。
session跨域應(yīng)該是問session如何共享：
1.session sticky，2. session replication，3. session數(shù)據(jù)集中存儲(chǔ)，4. cookie based；
?7. TCP三次握手、四次揮手（這個(gè)問題真的要回答吐了，不過真的是面試官最喜歡問的，建議每天手?jǐn)]一遍，而且不只是每次請求的過程，各種FIN_WAIT、TIME_WAIT狀態(tài)也要掌握） ?
參考自己的文章三次握手和四次揮手 - 簡書
8. 打開網(wǎng)頁到頁面顯示之間的過程（涵蓋了各個(gè)方面，DNS解析過程，Nginx請求轉(zhuǎn)發(fā)、連接建立和保持過程、瀏覽器內(nèi)容渲染過程，考慮的越詳細(xì)越好）一個(gè)網(wǎng)頁打開的全過程 - CSDN博客
一個(gè)網(wǎng)頁從請求到最終顯示的完整過程一般可分為如下7個(gè)步驟：
1. 在瀏覽器中輸入網(wǎng)址；
2. 發(fā)送至DNS服務(wù)器并獲得域名對應(yīng)的WEB服務(wù)器的IP地址；
3. 與WEB服務(wù)器建立TCP連接；
4. 瀏覽器向WEB服務(wù)器的IP地址發(fā)送相應(yīng)的HTTP請求；
5. WEB服務(wù)器響應(yīng)請求并返回指定URL的數(shù)據(jù)，或錯(cuò)誤信息，如果設(shè)定重定向，則重定向到新的URL地址 。
6. 瀏覽器下載數(shù)據(jù)后對頁面進(jìn)行渲染，即解析HTML源文件，解析的過程中實(shí)現(xiàn)對頁面的排版，解析完成后在瀏覽器中顯示基礎(chǔ)頁面。
7. 分析頁面中的超鏈接并顯示在當(dāng)前頁面，重復(fù)以上過程直至無超鏈接需要發(fā)送，完成全部顯示。
9. http和https區(qū)別，https在請求時(shí)額外的過程，https是如何保證數(shù)據(jù)安全的 ?
參考我自己的文章http和https的區(qū)別與聯(lián)系 - 簡書
? 10. IP地址子網(wǎng)劃分? ?
子網(wǎng)數(shù)、主機(jī)數(shù)與子網(wǎng)掩碼的關(guān)系 - CSDN博客
利用子網(wǎng)掩碼計(jì)算最大可用主機(jī)數(shù)
有一個(gè)A類IP地址，設(shè)其子網(wǎng)掩碼為255.252.0.0，將它劃分成若干子網(wǎng)絡(luò)，每個(gè)子網(wǎng)絡(luò)可用主機(jī)數(shù)有多少？
①將子網(wǎng)掩碼轉(zhuǎn)換成二進(jìn)制表示11111111.11111100.00000000.00000000（0代表的是主機(jī)位）
②統(tǒng)計(jì)一下它的主機(jī)位共有18位
③最大可用主機(jī)數(shù)就是2的18次方減2（除去全是0的網(wǎng)絡(luò)地址和全是1廣播地址），即每個(gè)子網(wǎng)絡(luò)最多有262142臺(tái)主機(jī)可
利用子網(wǎng)掩碼計(jì)算最大有效子網(wǎng)數(shù)
A類IP地址，子網(wǎng)掩碼為255.224.0.0，它所能劃分的最大有效子網(wǎng)數(shù)是多少？
①將子網(wǎng)掩碼轉(zhuǎn)換成二進(jìn)制表示11111111.11100000.00000000.00000000? （1代表的是網(wǎng)絡(luò)位）
②統(tǒng)計(jì)一下它的網(wǎng)絡(luò)位共有11位
③A類地址網(wǎng)絡(luò)位的基礎(chǔ)數(shù)是8，二者之間的位數(shù)差是3
④最大有效子網(wǎng)數(shù)就是2的3次方，即最多可以劃分8個(gè)子網(wǎng)絡(luò)，但是一般要去除全0和全1的子網(wǎng)，故8-2=6。
1. A類地址
⑴ A類地址第1字節(jié)為網(wǎng)絡(luò)地址，其它3個(gè)字節(jié)為主機(jī)地址。
⑵ A類地址范圍：1.0.0.1—126.255.255.254 ? ? ??默認(rèn)子網(wǎng)掩碼為：255.0.0.0 （網(wǎng)絡(luò)號(hào)全1，主機(jī)號(hào)全0）
⑶ A類地址中的私有地址和保留地址：
①10.X.X.X是私有地址（所謂的私有地址就是在互聯(lián)網(wǎng)上不使用，而被用在局域網(wǎng)絡(luò)中的地址）。
②127.X.X.X是保留地址，用做循環(huán)測試用的。
2. B類地址
⑴ B類地址第1字節(jié)和第2字節(jié)為網(wǎng)絡(luò)地址，其它2個(gè)字節(jié)為主機(jī)地址。
⑵ B類地址范圍：128.0.0.1—191.255.255.254。 ? ?默認(rèn)子網(wǎng)掩碼為：255.255.0.0；
⑶ B類地址的私有地址和保留地址
①172.16.0.0—172.31.255.255是私有地址
②169.254.X.X是保留地址。如果你的IP地址是自動(dòng)獲取IP地址，而你在網(wǎng)絡(luò)上又沒有找到可用的DHCP服務(wù)器。就會(huì)得到其中一個(gè)IP。
3. C類地址
⑴ C類地址第1字節(jié)、第2字節(jié)和第3個(gè)字節(jié)為網(wǎng)絡(luò)地址，第4個(gè)個(gè)字節(jié)為主機(jī)地址。另外第1個(gè)字節(jié)的前三位固定為110。
⑵ C類地址范圍：192.0.0.1—223.255.255.254。 ? ? ?默認(rèn)子網(wǎng)掩碼為：255.255.255.0；
⑶ C類地址中的私有地址：
192.168.X.X是私有地址。
4. D類地址
⑴ D類地址不分網(wǎng)絡(luò)地址和主機(jī)地址，它的第1個(gè)字節(jié)的前四位固定為1110。
⑵ D類地址范圍：224.0.0.1—239.255.255.254
5. E類地址
⑴ E類地址也不分網(wǎng)絡(luò)地址和主機(jī)地址，它的第1個(gè)字節(jié)的前五位固定為11110。
⑵ E類地址范圍：240.0.0.1—255.255.255.254
IP地址分為五類，A類保留給政府機(jī)構(gòu)，B類分配給中等規(guī)模的公司，C類分配給任何需要的人，D類用于組播，E類用于實(shí)驗(yàn)，各類可容納的地址數(shù)目不同
減去2是因?yàn)椋? 主機(jī)號(hào)全為1的IP稱為廣播地址；? 主機(jī)號(hào)全為0的IP稱為網(wǎng)絡(luò)號(hào)
? 11. POST和GET區(qū)別? ?
（1）HTTP定義了與服務(wù)器交互的不同方法，其中最基本的HTTP請求有五種：GET，POST，PUT，DELETE，HEAD，其中GET和HEAD被稱為安全方法，因?yàn)槭褂肎ET和HEAD的HTTP請求不會(huì)產(chǎn)生什么動(dòng)作。不會(huì)產(chǎn)生動(dòng)作意味著GET和HEAD的HTTP請求不會(huì)在服務(wù)器上產(chǎn)生任何結(jié)果。但是安全方法并不是什么動(dòng)作都不產(chǎn)生，這里的安全方法僅僅指不會(huì)修改信息。
根據(jù)HTTP規(guī)范，POST的請求可能會(huì)修改服務(wù)器上的資源。比如CSDN的博客，用戶提交一篇文章或者一個(gè)讀者提交評論是通過POST請求來實(shí)現(xiàn)的，因?yàn)樵偬峤晃恼禄蛘咴u論提交后資源（即某個(gè)頁面）不同了，或者說資源被修改了，這些便是“不安全方法”。
（2）get傳送的數(shù)據(jù)量較小，不能大于2KB。post傳送的數(shù)據(jù)量較大，一般被默認(rèn)為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB
（3）安全性不同：比方說通過GET請求了某個(gè)url，然后一些參數(shù)都明確的附在url后面了，查看瀏覽器歷史訪問的時(shí)候就可以看見了，一些文件也在訪問的同時(shí)被緩存了，而一般POST的則不會(huì)。
綜上所述：GET的HTTP請求不會(huì)修改服務(wù)器上的資源。而POST的請求可能會(huì)修改服務(wù)器上的資源
? 12. DNS解析過程?
? ? ?? 1、瀏覽器緩存：瀏覽器會(huì)按照一定的頻率緩存DNS記錄。
2、操作系統(tǒng)緩存：如果瀏覽器緩存中找不到需要的DNS記錄，那就去操作系統(tǒng)中找。
3、路由緩存：如果操作系統(tǒng)中找不到的話再去路由器中DNS緩存里面查找。
4、ISP的DNS服務(wù)器：路由器中還找不到的話，就去ISP中專門的DNS服務(wù)器查找。ISP是互聯(lián)網(wǎng)服務(wù)提供商(Internet?Service?Provider)的簡稱
? ? ?? 5、頂級域名服務(wù)器：ISP的DNS服務(wù)器還找不到的話，會(huì)隨機(jī)向一個(gè)頂級域名服務(wù)器（比如.com,? .net等這些頂級域名服務(wù)器）發(fā)出請求。比如我要找www.baidu.com這個(gè)網(wǎng)站，我剛好隨機(jī)訪問的是.com這個(gè)頂級域名服務(wù)器，那么就會(huì)直接返回baidu.com這個(gè)域的ip；如果不碰巧找的不是.com這個(gè)頂級域名服務(wù)器（比如找的是.net），那么這個(gè)頂級域名服務(wù)器就會(huì)再向根服務(wù)器查詢。
5、根服務(wù)器：頂級域名服務(wù)器沒有找到的話，就會(huì)向根服務(wù)器發(fā)出請求，根服務(wù)器會(huì)告訴請求的頂級域名服務(wù)器.com域名服務(wù)器的IP地址，這樣發(fā)出請求的.net頂級域名服務(wù)器就會(huì)直接去訪問.com頂級域名服務(wù)器；com域的服務(wù)器發(fā)現(xiàn)你這請求是baidu.com這個(gè)域的，我一查發(fā)現(xiàn)了這個(gè)域的NS（域名服務(wù)器記錄），那我就返回給ISPDNS ? baidu.com這個(gè)域的ip地址，你再去查。（目前百度有4臺(tái)baidu.com的頂級域名服務(wù)器）。ISPDNS不厭其煩的再次向baidu.com這個(gè)域的權(quán)威服務(wù)器發(fā)起請求，baidu.com收到之后，查了下有www的這臺(tái)主機(jī)，就把這個(gè)IP返回給你了，然后ISPDNS拿到了之后，將其返回給了客戶端，并且把這個(gè)保存在高速緩存中。
13. TCP如何保證數(shù)據(jù)的可靠傳輸?shù)模ㄟ@個(gè)問題可以引申出很多子問題，擁塞控制慢開始、擁塞避免、快重傳、滑動(dòng)窗口協(xié)議、停止等待協(xié)議、超時(shí)重傳機(jī)制，最好都能掌握） ? ? ? ? ? ? ?TCP 協(xié)議如何保證可靠傳輸 - 淺井光一 - 博客園
? ? ? ? ? tcp 慢啟動(dòng)，擁塞避免，快速重傳，快速恢復(fù) - NeverMore! - 博客園
自己筆記上有的。
慢開始：TCP發(fā)送方在初始階段是以指數(shù)的速度增加，即每過一個(gè)RTT將擁塞窗口（cwnd/congwin）的值翻倍，TCP發(fā)送方繼續(xù)以指數(shù)的速度增加其發(fā)送速度指導(dǎo)到達(dá)初始設(shè)定的慢啟動(dòng)門限ssthresh，之后會(huì)變成線性增長（每次加1）。
對超時(shí)事件做出反應(yīng)：當(dāng)受到3個(gè)冗余ACK后，TCP的擁塞窗口減小為當(dāng)前的一半，然后線性的增加
擁塞窗口：是對于數(shù)據(jù)發(fā)送端來說的，指發(fā)送端在一個(gè)RTT內(nèi)最大可以發(fā)送的數(shù)據(jù)包數(shù)量。
滑動(dòng)窗口：是接收端使用的窗口大小，用來告知發(fā)送端接收端的緩存大小，以此可以控制發(fā)送端發(fā)送數(shù)據(jù)的大小，從而達(dá)到控制流量的目的。
快恢復(fù)和快重傳一般都是一起使用的
快重傳步驟：（在某個(gè)報(bào)文段的定時(shí)器過期之前重傳丟失的報(bào)文段，或者一旦收到3個(gè)冗余ACK后就進(jìn)行重傳丟失的報(bào)文段）
? ?? 要求接收方每收到一個(gè)失序的報(bào)文段后就立即發(fā)出重復(fù)確認(rèn)而不是等待自己發(fā)送數(shù)據(jù)時(shí)才捎帶確認(rèn)
? ?? 發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就立即重傳對方尚未收到的報(bào)文段，而不必等待設(shè)置的重傳計(jì)時(shí)器到期
（1）當(dāng)收到3個(gè)重復(fù)ACK時(shí)，把ssthresh設(shè)置為cwnd的一半，
（2）把cwnd設(shè)置為ssthresh的值加3，然后重傳丟失的報(bào)文段，加3的原因是因?yàn)槭盏?個(gè)重復(fù)的ACK，表明有3個(gè)“老”的數(shù)據(jù)包離開了網(wǎng)絡(luò)（為什么有3個(gè)“老”的數(shù)據(jù)包離開了網(wǎng)絡(luò)？ 因?yàn)榭熘貍髦幸呀?jīng)規(guī)定要求接收方每收到一個(gè)失序的報(bào)文段后就立即發(fā)出重復(fù)確認(rèn)而不是等待自己發(fā)送數(shù)據(jù)時(shí)才捎帶確認(rèn)）
快速恢復(fù)步驟：（在收到3個(gè)冗余ACK之后取消慢加法增大的行為，Reno與Tahoe相比，增加了快速恢復(fù)階段，也就是說，完成快速重傳后，進(jìn)入了擁塞避免階段而不是慢啟動(dòng)階段。 ）
（1）當(dāng)收到新的數(shù)據(jù)包的ACK時(shí)，把cwnd設(shè)置為第一步中的ssthresh的值。原因是因?yàn)樵揂CK確認(rèn)了新的數(shù)據(jù)，說明從重復(fù)ACK時(shí)的數(shù)據(jù)都已收到，該恢復(fù)過程已經(jīng)結(jié)束，可以回到恢復(fù)之前的狀態(tài)了，也即再次進(jìn)入擁塞避免狀態(tài)。
14. 地址解析協(xié)議ARP ?TCP/IP協(xié)議——ARP詳解 - songoo - 博客園
地址解析協(xié)議（Address Resolution Protocol），其基本功能為透過目標(biāo)設(shè)備的IP地址，查詢目標(biāo)設(shè)備的MAC地址，以保證通信的順利進(jìn)行。（工作在局域網(wǎng)中的）
同一局域網(wǎng)中的一臺(tái)主機(jī)要和另一臺(tái)主機(jī)進(jìn)行直接通信，必須要知道目標(biāo)主機(jī)的MAC地址。而在TCP/IP協(xié)議中，網(wǎng)絡(luò)層和傳輸層只關(guān)心目標(biāo)主機(jī)的IP地址。這就導(dǎo)致在以太網(wǎng)中使用IP協(xié)議時(shí)，數(shù)據(jù)鏈路層的以太網(wǎng)協(xié)議接到上層IP協(xié)議提供的數(shù)據(jù)中，只包含目的主機(jī)的IP地址。于是需要一種方法，根據(jù)目的主機(jī)的IP地址，獲得其MAC地址。這就是ARP協(xié)議要做的事情。所謂地址解析（address resolution）就是主機(jī)在發(fā)送幀前將目標(biāo)IP地址轉(zhuǎn)換成目標(biāo)MAC地址的過程。
15. 交換機(jī)和路由器的區(qū)別
1.從外形上我們區(qū)分兩者，交換機(jī)通常端口比較多看起來比較笨重，而路由器的端口就少得多體積也小得多，
2.交換機(jī)工作在數(shù)據(jù)鏈路層，而路由器則工作在網(wǎng)絡(luò)層
3. 交換機(jī)是根據(jù)MAC地址轉(zhuǎn)發(fā)數(shù)據(jù)幀，而路由器則是根據(jù)IP地址來轉(zhuǎn)發(fā)IP數(shù)據(jù)報(bào)/分組。
4.交換機(jī)主要是用于組建局域網(wǎng)，而路由器則是負(fù)責(zé)讓主機(jī)連接外網(wǎng)
5.路由器不會(huì)轉(zhuǎn)發(fā)廣播數(shù)據(jù)，交換機(jī)會(huì)轉(zhuǎn)發(fā)廣播數(shù)據(jù)給局域網(wǎng)中的所有主機(jī)
16. DOS與DDOS攻擊的原理
DOS攻擊：一臺(tái)或多臺(tái)計(jì)算機(jī)對受攻擊服務(wù)器的某一個(gè)端口發(fā)送大量無關(guān)的UDP報(bào)文，導(dǎo)致整個(gè)通道內(nèi)的正常服務(wù)無法進(jìn)行。 ? ?
DDOS攻擊：大量的肉雞對服務(wù)器的不同端口發(fā)送巨型流量的UDP報(bào)文，無法通過關(guān)閉端口的方式來進(jìn)行隔離，破壞力極強(qiáng)，嚴(yán)重會(huì)造成服務(wù)器當(dāng)機(jī)。（listen有一個(gè)隊(duì)列，處理連接請求。在收到匿名IP發(fā)過來的SYN之后，會(huì)在listen隊(duì)列中存放一個(gè)記錄，但是隊(duì)列容量是有限的，當(dāng)這樣的惡意請求過多的時(shí)候，listen隊(duì)列里就塞滿了這些無效的連接請求，然后裝不下更多的連接記錄了，所以就拒絕其他請求了）
根據(jù)攻擊的時(shí)間和方式又可分將DDOS為以下幾種
1.SYN Flood
2.ACK Flood
3.Connection Flood
4.HTTP Get Flood
17.各個(gè)層尋址
運(yùn)輸層尋址：端口（port） ? ? ?? 網(wǎng)絡(luò)層尋址：IP ? ? ? ? 數(shù)據(jù)鏈路層： MAC
18.物聯(lián)網(wǎng)四大協(xié)議的基本介紹（記住MQTT，其他了解名字）
（1）MQTT（Message Queuing Telemetry Transport，消息隊(duì)列遙測傳輸）：是一個(gè)即時(shí)通訊協(xié)議，有可能成為物聯(lián)網(wǎng)的重要組成部分。該協(xié)議構(gòu)建于TCP/IP協(xié)議上，該協(xié)議支持所有平臺(tái)，幾乎可以把所有聯(lián)網(wǎng)物品和外部連接起來，被用來當(dāng)做傳感器和致動(dòng)器（比如通過Twitter讓房屋聯(lián)網(wǎng)）的通信協(xié)議，MQTT最大優(yōu)點(diǎn)在于，可以以極少的代碼和有限的帶寬，為連接遠(yuǎn)程設(shè)備提供實(shí)時(shí)可靠的消息服務(wù)。做為一種低開銷、低帶寬占用的即時(shí)通訊協(xié)議，使其在物聯(lián)網(wǎng)、小型設(shè)備、移動(dòng)應(yīng)用等方面有較廣泛的應(yīng)用。
（2）XMPP ： XMPP是一種基于標(biāo)準(zhǔn)通用標(biāo)記語言的子集XML的協(xié)議，它繼承了在XML環(huán)境中靈活的發(fā)展性。因此，基于XMPP的應(yīng)用具有超強(qiáng)的可擴(kuò)展性。經(jīng)過擴(kuò)展以后的XMPP可以通過發(fā)送擴(kuò)展的信息來處理用戶的需求，以及在XMPP的頂端建立如內(nèi)容發(fā)布系統(tǒng)和基于地址的服務(wù)等應(yīng)用程序。而且，XMPP包含了針對服務(wù)器端的軟件協(xié)議，使之能與另一個(gè)進(jìn)行通話，這使得開發(fā)者更容易建立客戶應(yīng)用程序或給一個(gè)已經(jīng)配置好XMPP協(xié)議的系統(tǒng)添加功能。?
（3）CoAP：受限制的應(yīng)用協(xié)議(Constrained Application Protocol)。在最近幾年的時(shí)間中，專家們預(yù)測會(huì)有更多的設(shè)備相互連接，而這些設(shè)備的數(shù)量將遠(yuǎn)超人類的數(shù)量。在這種大背景下，物聯(lián)網(wǎng)和M2M技術(shù)應(yīng)運(yùn)而生。雖然對人而言，連接入互聯(lián)網(wǎng)顯得方便容易，但是對于那些微型設(shè)備而言接入互聯(lián)網(wǎng)非常困難。在當(dāng)前由PC機(jī)組成的世界，信息交換是通過TCP和應(yīng)用層協(xié)議HTTP實(shí)現(xiàn)的。但是對于小型設(shè)備而言，實(shí)現(xiàn)TCP和HTTP協(xié)議顯然是一個(gè)過分的要求。為了讓小設(shè)備可以接入互聯(lián)網(wǎng)，CoAP協(xié)議被設(shè)計(jì)出來。CoAP是一種應(yīng)用層協(xié)議，它運(yùn)行于UDP協(xié)議之上而不是像HTTP那樣運(yùn)行于TCP之上。CoAP協(xié)議非常的小巧，最小的數(shù)據(jù)包僅為4字節(jié)。?
（4）REST 指的是一組 架構(gòu)約束條件和原則。滿足這些約束條件和原則的應(yīng)用程序或設(shè)計(jì)就是 RESTful。
Web 應(yīng)用程序最重要的 REST 原則是，客戶端和服務(wù)器之間的交互在請求之間是無狀態(tài)的。從客戶端到服務(wù)器的每個(gè)請求都必須包含理解請求所必需的信息。如果服務(wù)器在請求之間的任何時(shí)間點(diǎn)重啟，客戶端不會(huì)得到通知。此外，無狀態(tài)請求可以由任何可用服務(wù)器回答，這十分適合 云計(jì)算之類的環(huán)境?？蛻舳丝梢跃彺鏀?shù)據(jù)以改進(jìn)性能
19.TCP中的五個(gè)計(jì)時(shí)器
（1）重傳計(jì)時(shí)器(Retransmission Timer)：
目的：為了控制丟失的報(bào)文段或者丟棄的報(bào)文段。這段時(shí)間為對報(bào)文段的等待確認(rèn)時(shí)間。
創(chuàng)建時(shí)間：在TCP發(fā)送報(bào)文段時(shí)，會(huì)創(chuàng)建對次特定報(bào)文段的重傳計(jì)時(shí)器。
可能發(fā)生的兩種情況：在截止時(shí)間（通常為60秒）到之前，已經(jīng)收到了對此特定報(bào)文段的確認(rèn)，則撤銷計(jì)時(shí)器；在截止時(shí)間到了，但為收到對此特定報(bào)文段的確認(rèn)，則重傳報(bào)文段，并且將計(jì)時(shí)器復(fù)位。
重傳時(shí)間：2*RTT（Round Trip Time，為往返時(shí)間）
（2）堅(jiān)持計(jì)時(shí)器(Persistent Timer)：
目的：主要解決零窗口大小通知可能導(dǎo)致的死鎖問題
死鎖問題的產(chǎn)生：當(dāng)接收端的窗口大小為0時(shí)，接收端向發(fā)送端發(fā)送一個(gè)零窗口報(bào)文段，發(fā)送端即停止向?qū)邮斩税l(fā)送數(shù)據(jù)。此后，如果接收端緩存區(qū)有空間則會(huì)重新給發(fā)送端發(fā)送一個(gè)窗口大小，即窗口更新。但接收端發(fā)送的這個(gè)確認(rèn)報(bào)文段有可能會(huì)丟失，而此時(shí)接收端不知道已經(jīng)丟失并認(rèn)為自己已經(jīng)發(fā)送成功，則一直處于等待數(shù)據(jù)的狀態(tài)；而發(fā)送端由于沒有收到該確認(rèn)報(bào)文段，就會(huì)一直等待對方發(fā)來新的窗口大小，這樣一來，雙方都處在等待對方的狀態(tài)，這樣就形成了一種死鎖問題。如果沒有應(yīng)對措施，這種局面是不會(huì)被打破的。為了解決這種問題，TCP為每一個(gè)連接設(shè)置了堅(jiān)持計(jì)時(shí)器。
工作原理：當(dāng)發(fā)送端TCP收到接收端發(fā)來的零窗口通知時(shí)，就會(huì)啟動(dòng)堅(jiān)持計(jì)時(shí)器。當(dāng)計(jì)時(shí)器的期限到達(dá)時(shí)，發(fā)送端就會(huì)主動(dòng)發(fā)送一個(gè)特殊的報(bào)文段告訴對方確認(rèn)已經(jīng)丟失，必須重新發(fā)送?！具@個(gè)特殊的報(bào)文段就稱為探測報(bào)文段，探測報(bào)文段只有1個(gè)字節(jié)的大小，里邊只有一個(gè)序號(hào)，該序號(hào)不需要被確認(rèn)，甚至在計(jì)算其他部分?jǐn)?shù)據(jù)的確認(rèn)時(shí)該序號(hào)會(huì)被忽略?！?/p>
截止期的設(shè)置：設(shè)置為重傳時(shí)間的值。但如果沒有收到接收端的響應(yīng)，則會(huì)發(fā)送另一個(gè)探測報(bào)文段，并將計(jì)時(shí)器的值加倍并復(fù)位，直到大于門限值（一般為60秒）。在此之后，發(fā)送端會(huì)每隔60秒發(fā)送一個(gè)探測報(bào)文段，直到窗口重新打開。
（3）保活計(jì)時(shí)器(Keeplive Timer)：
目的：主要是為了防止兩個(gè)TCP連接出現(xiàn)長時(shí)間的空閑。當(dāng)客戶端與服務(wù)器端建立TCP連接后，很長時(shí)間內(nèi)客戶端都沒有向服務(wù)器端發(fā)送數(shù)據(jù)，此時(shí)很有可能是客戶端出現(xiàn)故障，而服務(wù)器端會(huì)一直處于等待狀態(tài)。?；钣?jì)時(shí)器就是解決這種問題而生的。
工作原理：每當(dāng)服務(wù)器端收到客戶端的數(shù)據(jù)時(shí)，都將?；钣?jì)時(shí)器重新設(shè)置（通常設(shè)置為2小時(shí)）。過了2小時(shí)后，服務(wù)器端如果沒有收到客戶端的數(shù)據(jù)，會(huì)發(fā)送探測報(bào)文段給客戶端，并且每隔75秒發(fā)送一個(gè)，當(dāng)連續(xù)發(fā)送10次以后，仍沒有收到對端的來信，則服務(wù)器端認(rèn)為客戶端出現(xiàn)故障，并會(huì)終止連接。
（4）時(shí)間等待計(jì)時(shí)器(Time_Wait Timer)：
時(shí)間等待計(jì)時(shí)器是在連接終止期間使用的。當(dāng)TCP關(guān)閉連接時(shí)并不是立即關(guān)閉的，在等待期間，連接還處于過渡狀態(tài)。這樣就可以使重復(fù)的FIN報(bào)文段在到達(dá)終點(diǎn)之后被丟棄。
時(shí)間設(shè)置：一般為報(bào)文段壽命期望值的2倍。
（5）2MSL（2倍報(bào)文段最大生存時(shí)間）計(jì)時(shí)器
? ? ?? TCP的TIME_WAIT狀態(tài)也稱為2MSL等待狀態(tài)
20. Nagle算法 &&nagle算法的CORK選項(xiàng)
（1）Nagle算法的基本定義：任意時(shí)刻，最多只能有一個(gè)未被確認(rèn)的小段。 所謂“小段”，指的是小于MSS尺寸的數(shù)據(jù)塊，所謂“未被確認(rèn)”，是指一個(gè)數(shù)據(jù)塊發(fā)送出去后，沒有收到對方發(fā)送的ACK確認(rèn)該數(shù)據(jù)已收到。
? ? ? TCP/IP協(xié)議中，無論發(fā)送多少數(shù)據(jù)，總是要在數(shù)據(jù)前面加上協(xié)議頭，同時(shí)，對方接收到數(shù)據(jù)，也需要發(fā)送ACK表示確認(rèn)。為了盡可能的利用網(wǎng)絡(luò)帶寬，TCP總是希望盡可能的發(fā)送足夠大的數(shù)據(jù)。（一個(gè)連接會(huì)設(shè)置?最大報(bào)文段長度MSS參數(shù)，因此，TCP/IP希望每次都能夠以MSS尺寸的數(shù)據(jù)塊來發(fā)送數(shù)據(jù)）。Nagle算法就是為了盡可能發(fā)送大塊數(shù)據(jù)，避免網(wǎng)絡(luò)中充斥著許多小數(shù)據(jù)塊（算法目的，通過cork選項(xiàng)來實(shí)現(xiàn)）。Nagle算法只允許一個(gè)未被ACK的包存在于網(wǎng)絡(luò)，它并不管包的大小，因此它事實(shí)上就是一個(gè)擴(kuò)展的停-等協(xié)議，只不過它是基于包停-等的，而不是基于字節(jié)停-等的。Nagle算法完全由TCP協(xié)議的ACK機(jī)制決定，這會(huì)帶來一些問題，比如如果對端ACK回復(fù)很快的話，Nagle事實(shí)上不會(huì)拼接太多的數(shù)據(jù)包，雖然避免了網(wǎng)絡(luò)擁塞，網(wǎng)絡(luò)總體的利用率依然很低。
Nagle算法的規(guī)則（可參考tcp_output.c文件里tcp_nagle_check函數(shù)注釋）：
?? ? ?（1）如果包長度達(dá)到MSS，則允許發(fā)送；
?? ? ?（2）如果該包含有FIN，則允許發(fā)送；
?? ? ?（3）設(shè)置了TCP_NODELAY選項(xiàng)，則允許發(fā)送；
?? ? ?（4）未設(shè)置TCP_CORK選項(xiàng)時(shí)，若所有發(fā)出去的小數(shù)據(jù)包（包長度小于MSS）均被確認(rèn)，則允許發(fā)送；
?? ? ?（5）上述條件都未滿足，但發(fā)生了超時(shí)（一般為200ms），則立即發(fā)送。
tcp_nodelay：禁止nagle算法，有需要發(fā)送的就立即發(fā)送
（2）TCP_CORK 選項(xiàng)（CORK算法）
所謂的CORK就是塞子的意思，形象地理解就是用CORK將連接塞住，使得數(shù)據(jù)先不發(fā)出去，等到拔去塞子后再發(fā)出去。設(shè)置該選項(xiàng)后，內(nèi)核會(huì)盡力把小數(shù)據(jù)包拼接成一個(gè)大的數(shù)據(jù)包（一個(gè)MTU）再發(fā)送出去，當(dāng)然若一定時(shí)間后（一般為200ms，該值尚待確認(rèn)），內(nèi)核仍然沒有組合成一個(gè)MTU時(shí)也必須發(fā)送現(xiàn)有的數(shù)據(jù)（不可能讓數(shù)據(jù)一直等待吧）。
然而，TCP_CORK的實(shí)現(xiàn)可能并不像你想象的那么完美，CORK并不會(huì)將連接完全塞住。內(nèi)核其實(shí)并不知道應(yīng)用層到底什么時(shí)候會(huì)發(fā)送第二批數(shù)據(jù)用于和第一批數(shù)據(jù)拼接以達(dá)到MTU的大小，因此內(nèi)核會(huì)給出一個(gè)時(shí)間限制，在該時(shí)間內(nèi)沒有拼接成一個(gè)大包（努力接近MTU最大傳輸單元）的話，內(nèi)核就會(huì)無條件發(fā)送。
也就是說若應(yīng)用層程序發(fā)送小包數(shù)據(jù)的間隔不夠短時(shí)，TCP_CORK就沒有一點(diǎn)作用，反而失去了數(shù)據(jù)的實(shí)時(shí)性（每個(gè)小包數(shù)據(jù)都會(huì)延時(shí)一定時(shí)間再發(fā)送）。
21. 實(shí)現(xiàn)一個(gè)可靠的UDP協(xié)議
? ? ? ? 實(shí)現(xiàn)一個(gè)最基礎(chǔ)的可靠udp通訊協(xié)議，我們只需要提供一個(gè)重傳機(jī)制即可。在這我實(shí)現(xiàn)了一個(gè)簡單的可靠udp協(xié)議，具體的實(shí)現(xiàn)方式如下（1）（2）：
? ? ?? （1）為每一個(gè)發(fā)送出去的udp數(shù)據(jù)包分配一個(gè)包id，每次接收方收到一個(gè)數(shù)據(jù)包時(shí)，都要回應(yīng)發(fā)送方一個(gè)ack對應(yīng)這個(gè)包id。協(xié)議通過這種確認(rèn)機(jī)制來保證接收方能收到發(fā)送方發(fā)出的udp數(shù)據(jù)包；
? ? ? ? （2）在發(fā)出的時(shí)候，發(fā)送方應(yīng)該設(shè)置一個(gè)計(jì)時(shí)器，超時(shí)的話會(huì)重傳數(shù)據(jù)包。
具體來說它沒做這些事情：
（1）它沒有保證包的有序性。發(fā)送方連續(xù)發(fā)送幾個(gè)udp數(shù)據(jù)包，接收方可以以任何順序收到這幾個(gè)數(shù)據(jù)包。如果想要做到有序性，必須由應(yīng)用層來完成。
（2）它沒做流量控制。發(fā)送方連續(xù)大量發(fā)送數(shù)據(jù)包會(huì)導(dǎo)致網(wǎng)絡(luò)性能變差，丟包次數(shù)增大。
（3）它沒對數(shù)據(jù)包大小做控制。為了避免IP層對數(shù)據(jù)包進(jìn)行分片，應(yīng)用層應(yīng)該要保證每個(gè)數(shù)據(jù)包的大小不超過MTU最大傳輸單元。如果這個(gè)數(shù)據(jù)包會(huì)經(jīng)過廣域網(wǎng)（一般情況下）這個(gè)值應(yīng)該不超過576?？紤]到IP頭的20字節(jié)，udp頭的8個(gè)字節(jié)，以及這個(gè)協(xié)議頭的字節(jié)。最好每次發(fā)送的數(shù)據(jù)大小在512以內(nèi)。
22.WebSocket協(xié)議 ??WebSocket協(xié)議：5分鐘從入門到精通 - 程序猿小卡 - 博客園
WebSocket協(xié)議：? HTML5開始提供的一種瀏覽器與服務(wù)器進(jìn)行全雙工通訊的網(wǎng)絡(luò)技術(shù)，屬于應(yīng)用層協(xié)議。它基于TCP傳輸協(xié)議，并復(fù)用HTTP的握手通道。
WebSocket協(xié)議就是html5中的一種協(xié)議，我的理解是，他是對html的長連接的一種升級。你也可以將它理解成一種長連接。
（1）websocket連接只需要建立一次，在第一次連接的時(shí)候，客戶端和服務(wù)器會(huì)交換必要的信息；它只需要建立一次連接，傳遞一次必要的請求頭和響應(yīng)頭信息，之后再傳遞數(shù)據(jù)的時(shí)候就不需要在交換這些信息了。節(jié)省了帶寬。
（2）websocket的鏈接一旦建立，服務(wù)器和客戶端都可以互推信息
特點(diǎn)：（1）WebSocket可以在瀏覽器里使用（2）支持雙向通信（3）使用很簡單
1. WebSocket協(xié)議如何建立連接
1）客戶端：申請協(xié)議升級：首先，客戶端發(fā)起協(xié)議升級請求。采用的是標(biāo)準(zhǔn)的HTTP報(bào)文格式，且只支持get方法。
2）服務(wù)端：響應(yīng)協(xié)議升級
服務(wù)端返回內(nèi)容如下，狀態(tài)代碼101表示協(xié)議切換。到此完成協(xié)議升級，后續(xù)的數(shù)據(jù)交互都按照新的協(xié)議來
3）Sec-WebSocket-Accept的計(jì)算
優(yōu)點(diǎn)
與HTTP協(xié)議相比，WebSocket的優(yōu)點(diǎn)是：支持雙向通信，更靈活，更高效，可擴(kuò)展性更好。
（1）支持雙向通信，實(shí)時(shí)性更強(qiáng)。
（2）更好的二進(jìn)制支持。
（3）較少的控制開銷。連接創(chuàng)建后，ws（WebService ? 瀏覽器）客戶端、服務(wù)端進(jìn)行數(shù)據(jù)交換時(shí)，協(xié)議控制的數(shù)據(jù)包頭部較小。在不包含頭部的情況下，服務(wù)端到客戶端的包頭只有2~10字節(jié)（取決于數(shù)據(jù)包長度），客戶端到服務(wù)端的的話，需要加上額外的4字節(jié)的掩碼。而HTTP協(xié)議每次通信都需要攜帶完整的頭部。
（4）支持?jǐn)U展。ws協(xié)議定義了擴(kuò)展，用戶可以擴(kuò)展協(xié)議，或者實(shí)現(xiàn)自定義的子協(xié)議。（比如支持自定義壓縮算法等）
23 .CSMA/CD協(xié)議(載波監(jiān)聽多點(diǎn)接入/碰撞檢測協(xié)議)
? ? ? ? ? ? ? ? ?? 即帶沖突檢測的載波監(jiān)聽多路訪問技術(shù)
碰撞檢測：計(jì)算機(jī)邊發(fā)送數(shù)據(jù)邊檢測信道上的信號(hào)電壓大小
載波監(jiān)聽：用電子技術(shù)檢測總線上有沒有其他計(jì)算機(jī)發(fā)送數(shù)據(jù)信號(hào)
網(wǎng)絡(luò)適配器的作用
網(wǎng)絡(luò)適配器里面裝有處理器和存儲(chǔ)器；適配器和局域網(wǎng)之間的通信是通過電纜
或雙絞線以串行的傳輸方式進(jìn)行的，但是適配器和計(jì)算機(jī)之間的通信則是通過計(jì)算
主板上的IO總線以并行傳輸?shù)模贿m配器的一個(gè)重要功能就是進(jìn)行數(shù)據(jù)串行傳輸和數(shù)
據(jù)并行傳輸?shù)霓D(zhuǎn)換。操作系統(tǒng)中安裝有網(wǎng)絡(luò)適配器的設(shè)備驅(qū)動(dòng)程序來管理網(wǎng)絡(luò)適配器。適配器接收和
發(fā)送幀時(shí)不使用計(jì)算機(jī)的CPU，只有當(dāng)正確收到幀時(shí)，才中斷通知計(jì)算機(jī)并交付協(xié)
議棧中的網(wǎng)絡(luò)層。
(1) 準(zhǔn)備發(fā)送：適配器從網(wǎng)絡(luò)層獲得一個(gè)分組，加上以太網(wǎng)的首部和尾部，組成以太網(wǎng)幀，放入網(wǎng)卡的緩存中，但在發(fā)送之前，必須先檢測信道。
(2) 檢測信道：不停地檢測信道，一直等待信道空閑，并在96比特時(shí)間內(nèi)信道保持空閑（保證了幀間最小時(shí)間間隔），就發(fā)送這個(gè)幀。
(3) 在發(fā)送過程中仍不停地檢測信道，即網(wǎng)絡(luò)適配器要邊發(fā)送邊監(jiān)聽。這里只有兩種可能性：
? ? ? ? 1)? 發(fā)送成功：在爭用期內(nèi)一直未檢測到碰撞，這個(gè)幀發(fā)送成功，回到（1）
? ? ? ? 2)? 發(fā)送失?。?b>在爭用期內(nèi)檢測到碰撞，就會(huì)立即停止發(fā)送數(shù)據(jù)，并發(fā)送一個(gè)48比特的阻塞信號(hào)。適配器接著就執(zhí)行指數(shù)退避算法，等待r倍512比特時(shí)間后，返回到步驟（2），繼續(xù)檢測信道。若重傳16次仍不能成功，則停止 ? 重傳向上報(bào)錯(cuò)。
試述二進(jìn)制指數(shù)退避算法規(guī)則。
在CSMA/CD協(xié)議中，一旦檢測到?jīng)_突，為降低再?zèng)_突的概率，需要等待一個(gè)隨機(jī)時(shí)間，然后再使用CSMA方法試圖傳輸。為了保證這種退避維持穩(wěn)定，采用了二進(jìn)制指數(shù)退避算法的技術(shù)，其算法過程如下:
1.將沖突發(fā)生后的時(shí)間劃分為長度為2t的時(shí)隙
2.?發(fā)生第一次沖突后，各個(gè)站點(diǎn)等待0或1個(gè)時(shí)隙在開始重傳
3.?發(fā)生第二次沖突后，各個(gè)站點(diǎn)隨機(jī)地選擇等待0,1，2或3個(gè)時(shí)隙在開始重傳
4.第i次沖突后，在0至2的i次方減一間隨機(jī)地選擇一個(gè)等待的時(shí)隙數(shù)，在開始重傳
5.10次沖突后，選擇等待的時(shí)隙數(shù)固定在0至1023（2的10次方減一）間
6.16次沖突后，發(fā)送失敗，報(bào)告上層。
即帶沖突檢測的載波監(jiān)聽多路訪問技術(shù)
24. PPP點(diǎn)對點(diǎn)協(xié)議
是一個(gè)運(yùn)行與點(diǎn)對點(diǎn)鏈路之上的鏈路層協(xié)議，即一條直接連接兩個(gè)節(jié)點(diǎn)的鏈路，鏈路的每一端有一個(gè)節(jié)點(diǎn)
點(diǎn)對點(diǎn)協(xié)議 PPP - CSDN博客
25.? 移動(dòng)端300毫秒延遲，怎么解決的？? ?
? 原因：移動(dòng)端瀏覽器會(huì)有一些默認(rèn)的行為，比如雙擊縮放、雙擊滾動(dòng)。這些行為，尤其是雙擊縮放，主要是為桌面網(wǎng)站在移動(dòng)端的瀏覽體驗(yàn)設(shè)計(jì)的。而在用戶對頁面進(jìn)行操作的時(shí)候，移動(dòng)端瀏覽器會(huì)優(yōu)先判斷用戶是否要觸發(fā)默認(rèn)的行為。所以會(huì)造成移動(dòng)端300ms延遲。
解決方案：（1）禁用縮放
當(dāng)HTML文檔頭部包含如下meta標(biāo)簽時(shí)，表明這個(gè)頁面是不可縮放的，那雙擊縮放的功能就沒有意義了，此時(shí)瀏覽器可以禁用默認(rèn)的雙擊縮放行為并且去掉300ms的點(diǎn)擊延遲。
（2）更改默認(rèn)的視口寬度
通過以下標(biāo)簽來設(shè)置視口寬度為設(shè)備寬度
（3）CSS touch-action
? ? ? ?? 跟300ms點(diǎn)擊延遲相關(guān)的，是touch-action這個(gè)CSS屬性。這個(gè)屬性指定了相應(yīng)元素上能夠觸發(fā)的用戶代理（也就是瀏覽器）的默認(rèn)行為。如果將該屬性值設(shè)置為touch-action:none，那么表示在該元素上的操作不會(huì)觸發(fā)用戶代理的任何默認(rèn)行為，就無需進(jìn)行300ms的延遲判斷。
26.? 304狀態(tài)碼是怎么樣，怎么產(chǎn)生的？------>Etag值怎么產(chǎn)生的？
304狀態(tài)碼產(chǎn)生：如果客戶端發(fā)送了一個(gè)帶條件的GET 請求且該請求已被允許，而文檔的內(nèi)容（自上次訪問以來或者根據(jù)請求的條件）并沒有改變，則服務(wù)器應(yīng)當(dāng)返回這個(gè)304狀態(tài)碼。簡單的表達(dá)就是：客戶端已經(jīng)執(zhí)行了GET，但文件未變化。
Etag值：是實(shí)體標(biāo)簽(Entity Tag)的縮寫。ETag是一個(gè)可以與Web資源關(guān)聯(lián)的記號(hào)（token）。ETag一般不以明文形式相應(yīng)給客戶端。在資源的各個(gè)生命周期中，它都具有不同的值，用于標(biāo)識(shí)出資源的狀態(tài)。當(dāng)資源發(fā)生變更時(shí)，如果其頭信息中一個(gè)或者多個(gè)發(fā)生變化，或者消息實(shí)體發(fā)生變化，那么ETag也隨之發(fā)生變化。 ??ETag詳解 - CSDN博客
ETag值的變更說明資源狀態(tài)已經(jīng)被修改。往往可以通過時(shí)間戳就可以便宜的得到ETag頭信息。在服務(wù)端中如果發(fā)回給消費(fèi)者的相應(yīng)從一開始起就由ETag控制，那么可以確保更細(xì)粒度的ETag升級完全由服務(wù)來進(jìn)行控制。服務(wù)計(jì)算ETag值，并在相應(yīng)客戶端請求時(shí)將它返回給客戶端。
27.? ? 微信掃一掃二維碼網(wǎng)頁上登陸前后端過程？?
微信PC端網(wǎng)頁版掃一掃登錄內(nèi)部實(shí)現(xiàn)原理_QQ技巧_QQ地帶
微信掃碼登錄核心過程應(yīng)該是這樣的：瀏覽器獲得一個(gè)唯一的、臨時(shí)的UUID（通用唯一識(shí)別碼，由一組32位數(shù)的16進(jìn)制數(shù)字所構(gòu)成），通過長連接等待客戶端掃描帶有此UUID的二維碼后，從長連接中獲得客戶端上報(bào)給服務(wù)器的帳號(hào)信息進(jìn)行展示。并在客戶端點(diǎn)擊確認(rèn)后，獲得服務(wù)器授信的令牌，進(jìn)行隨后的信息交互過程。 在超時(shí)、網(wǎng)絡(luò)斷開、其他設(shè)備上登錄后，此前獲得的令牌或丟失、或失效，對授權(quán)過程形成有效的安全防護(hù)，類似的應(yīng)用還有掃碼支付、掃碼加公眾號(hào)等功能 。
28.?一個(gè)頁面, 一個(gè)提交按鈕, 如何防止重復(fù)提交？（表單防止重復(fù)提交的四種方式 - Herrt灬凌夜 - 博客園）
（1）在數(shù)據(jù)庫添加唯一字段
? ? ? ? 在數(shù)據(jù)庫建表的時(shí)候在ID字段添加主鍵約束，賬號(hào)，名稱的信息添加唯一性約束。確保數(shù)據(jù)庫只可以添加一條數(shù)據(jù)。此方法最有效的防止了數(shù)據(jù)重復(fù)提交
（2）用js為添加禁用
當(dāng)用戶提交表單之后，可以使用js將提交按鈕隱藏（disable屬性），防止用戶多次點(diǎn)擊按鈕提交數(shù)據(jù)。
（3）使用Post/Redirect/Get
? ? ? ?? Post/Redirect/Get簡稱PRG，是一種可以防止表單數(shù)據(jù)重復(fù)提交的一種Web設(shè)計(jì)模式，像用戶刷新提交響應(yīng)頁面等比較典型的重復(fù)提交表單數(shù)據(jù)的問題可以使用PRG模式來避免。例如：當(dāng)用戶提交成功之后，執(zhí)行客戶端重定向，跳轉(zhuǎn)到提交成功頁面。
（4）使用session設(shè)置令牌
? ? ? ? 產(chǎn)生頁面時(shí)，服務(wù)器為每次產(chǎn)生的Form（表單）分配唯一的隨機(jī)標(biāo)識(shí)號(hào)，并且在form的一個(gè)隱藏字段中設(shè)置這個(gè)標(biāo)識(shí)號(hào)，同時(shí)在當(dāng)前用戶的Session中保存這個(gè)標(biāo)識(shí)號(hào)。當(dāng)提交表單時(shí)，服務(wù)器比較hidden和session中的標(biāo)識(shí)號(hào)是否相同，相同則繼續(xù)，處理完后清空Session，否則服務(wù)器忽略請求。
29.?TCP和http的區(qū)別
HTTP與TCP的聯(lián)區(qū)別，主要是圍繞著兩句話鋪開的。
第一句話：TCP/IP 協(xié)議是傳輸層協(xié)議，主要解決數(shù)據(jù)在網(wǎng)絡(luò)中如何傳輸?shù)膯栴}。
第二句話：HTTP 協(xié)議是應(yīng)用層協(xié)議，主要解決如何包裝數(shù)據(jù)，是基于TCP連接的。
我們在傳輸數(shù)據(jù)的時(shí)候，可以只使用傳輸層（如TCP協(xié)議），但是那樣就無法識(shí)別數(shù)據(jù)內(nèi)容，如果想使得傳輸?shù)臄?shù)據(jù)有意義，則必須使用應(yīng)用層協(xié)議（如HTTP協(xié)議）。就比如說，WEB使用HTTP作為應(yīng)用層協(xié)議，以便封裝HTTP文本信息，然后使用TCP/IP做傳輸層協(xié)議將它發(fā)送到網(wǎng)絡(luò)上去。
30.?Socket連接是否與服務(wù)器斷開
（1）通過心跳包：所謂的心跳包就是客戶端定時(shí)發(fā)送簡單的信息給服務(wù)器端告訴它我還在。代碼就是每隔幾分鐘發(fā)送一個(gè)固定信息給服務(wù)端，服務(wù)端收到后回復(fù)一個(gè)固定信息，如果服務(wù)端幾分鐘內(nèi)沒有收到客戶端信息則視客戶端斷開
（2）?發(fā)送之前用MSG_PEEK的方式recv。 看recv的返回值是否0字節(jié)，如果是0字節(jié)，說明對方發(fā)送了fin包，已關(guān)閉了連接。allan給出TTC中驗(yàn)證連接是否有效的函數(shù)：
