1. 網絡架構
自下而上對各層的作用進行簡單介紹：
- 物理層：屏蔽介質和設備差異實現相鄰計算機節點之間比特流的透明傳輸（網卡、集線器）。
- 數據鏈路層: 將物理層的比特流封裝成幀，在相鄰結點之間傳輸，這一層還需要實現差錯控制和流量控制（網橋、交換機）。
- 網絡層：網絡層的任務就是選擇合適的網間路由和交換結點，確保數據及時傳送（IP、ICMP、IGMP、ARP、RARP）（路由器、三層交換機）。
- 運輸層：負責向兩台主機進程之間的通信提供通用的數據傳輸服務(TCP、UDP)，（網關）。
- 會話層: 用戶應用程序和網絡之間的接口，主要包括用戶建立、維護和管理會話。
- 表示層：解釋應用層的命令和數據，如編碼、數據格式轉換和加密解密。
- 應用層：提供應用層協議，如HTTP協議，FTP協議等等，方便應用程序之間進行通信。
2. TCP/UDP
2.1 TCP 三次握手
（1） 建立TCP連接的目的：
為了准確無誤的把數據送達目標處，TCP采用三次握手策略建立連接。
（2）具體過程：
⼀次握⼿: 客戶端–> 發送帶有 SYN 標志的數據包 –> 服務端
⼆次握⼿: 服務端–> 發送帶有 SYN/ACK 標志的數據包 –> 客戶端
三次握⼿: 客戶端–> 發送帶有帶有 ACK 標志的數據包 –> 服務端
半連接隊列：TCP握手中，當服務器處於SYN_RCVD 狀態，服務器會把此種狀態下請求連接放在一個隊列里，該隊列稱為半連接隊列。
SYN攻擊:SYN攻擊即是利用TCP協議的缺陷，通過發送大量的半連接請求，占用半連接隊列，耗費CPU和內存資源。優化方式：（1）縮短SYN Timeout時間； （2）記錄IP，若連續受到某個IP的重復SYN報文，從這個IP地址來的包會被一概丟棄。
（3）為什么要三次握手，而不是兩次或者四次?
答：TCP采用的是全雙工的通信方式，三次握手最主要的目的就是通信雙方確保自己與對方發送與接收數據的過程是正常的，只有兩次的話，客戶端這邊沒有問題，但是服務器端只知道對方發送正常，自己接收正常，不知道客戶端接收正常不正常。三次能到達互相確認的目的，因此不需要第四次握手。每一次握手能夠到達的效果是:
** 第⼀次握⼿：Client什么都不能確認；Server確認了對⽅發送正常，⾃⼰接收正常。第⼆次握⼿：Client 確認了：⾃⼰發送、接收正常，對⽅發送、接收正常；Server 確認了：對⽅發送正常，⾃⼰接收正常。第三次握⼿：Client 確認了：⾃⼰發送、接收正常，對⽅發送、接收正常；Server 確認了：⾃⼰發送、接收正常，對⽅發送、接收正常。
所以三次握⼿就能確認雙發收發功能都正常，缺⼀不可。
（4）為什么要傳回SYN？
答： 接收端傳回發送端所發送的 SYN 是為了告訴發送端，我接收到的信息確實就是你所發送的信號。
（5）傳了SYN，為啥還要傳ACK？ （這個回答就和為什么不是兩次握手差不多）
答： 雙⽅通信⽆誤必須是兩者互相發送信息都⽆誤。傳了 SYN，證明發送⽅到接收⽅的通道沒有問題，但是接收⽅到發送⽅的通道還需要 ACK 信號來進⾏驗證。**
2.2 TCP 四次揮手
（1） 具體過程
（2）為什么要四次揮手？
答：任何⼀⽅都可以在數據傳送結束后發出連接釋放的通知，待對⽅確認后進⼊半關閉狀態。當另⼀⽅也沒有數據再發送的時候，則發出連接釋放通知，對⽅確認后就完全關閉了TCP連接，因此四次揮手是為了確保通信雙方都釋放連接。
舉個例⼦：A 和 B 打電話，通話即將結束后，A 說“我沒啥要說的了”，B回答“我知道了”，但是 B可能還會有要說的話，A 不能要求 B 跟着⾃⼰的節奏結束通話，於是 B 可能⼜巴拉巴拉說了⼀通，最后 B 說“我說完了”，A 回答“知道了”，這樣通話才算結束。
（3）為什么還要等待2MSL（最長報文段壽命）？
答：MSL表示報文最大生存時間，等待2MSL主要是：（1）為了確保客戶端A發給服務器B的最后一個ACK報文能夠到達服務器B，客服端發送給服務端的ACK可能會丟失，服務器收不到ACK會在發送一個FIN給客戶端，如果客戶端關閉了，服務端永遠收不到ACK，就不能正常關閉。（2） 可以保證上一次連接的報文已經在網絡中消失，不會出現與新TCP連接報文沖突的情況。
2.3 TCP和UDP的區別?
（1）TCP是面向連接的可靠傳輸，保證數據的正確性和順序性，傳輸效率慢，以字節流的形式傳輸，TCP通過三次握手和四次揮手建立和釋放連接，TCP通過校驗和、流量控制和擁塞控制實現可靠傳輸，主要用於文件和郵件傳輸，在傳輸層采用TCP的應用層協議主要有FTP、SMTP、HTTP，另外TCP報文的首部的固定部分為20個字節。
（2）UDP 在傳送數據之前不需要先建立連接，不提供可靠交付，傳輸效率快，以報文形式傳輸，雖然 UDP 不提供可靠交付，但在QQ 語⾳、 QQ 視頻 、直播等即時通信場景中 UDP 卻是⼀種最有效的⼯作⽅式。在傳輸層采用UDP的應用層協議主要有DNS、TFTP、DHCP和SNMP，另外UDP的首部只有8個字節，分別是源端口、目的端口、長度、校驗和。
2.4 TCP如何保證可靠傳輸?
（1）檢驗和：通過檢查校驗和，確認在傳輸過程中沒有發生差錯。
（2）流量控制：發送方的發送速度太快了，接收方來不及接受，利用滑動窗口來實現流量控制，控制數據發送速度，防止分組丟失。
（3）擁塞控制:根據網絡的擁塞程度來調整擁塞窗口的大小，當網絡發生擁塞時，減小擁塞窗口的大小，減少數據發送，避免網絡負載過大。TCP的擁塞控制采用了四種算法，即 慢開始 、 擁塞避免 、快重傳 和 快恢復。 慢開始：發送方剛開始不知道網絡的擁塞情況，先試探一下，由小到大的增加擁塞窗口。擁塞避免：緩慢增加擁塞口,每經過一個往返就加一。快重傳和快恢復：快速恢復丟失的數據包。避免要求重傳時的暫停。
（4）ARQ協議 ：停止等待ARQ：發送端在發送一個分組之后就停止，等待返回來的確認，如果等待一段時間沒有收到就重發。連續ARQ：發送方維護一個發送窗口，連續發送窗口的分組，接收方等待最后一個分組發送過來，再發送確認。
（5）超時重傳：當 TCP 發出⼀個段后，它啟動⼀個定時器，等待⽬的端確認收到這個報⽂段。如果不能及時收到⼀個確認，將重發這個報⽂段。
2.5 UDP如何保證可靠傳輸？
- UDP是傳輸層應用，本身是不可靠的，只能在應用層下功夫，模仿TCP的可靠傳輸，應答確認 （Seq/Ack應答機制），超時重傳（定時器），有序傳輸（將數據包進行編號，按照包的順序接收並存儲）,並且還要實現擁塞控制和可靠傳輸。
- 開源程序利用udp實現了可靠的數據傳輸，分別為RUDP、RTP、UDT。
2.6 簡述TCP粘包現象？
TCP是面向流的協議，發送的單位是字節流，因此會將多個小尺寸數據被封裝在一個tcp報文中發出去的可能性。 可以簡單的理解成客戶端調用了兩次send，服務器端一個recv就把信息都讀出來了。
2.7 TCP粘包現象處理方法？
2.8 TCP 的流量控制?
TCP利⽤滑動窗⼝實現流量控制。流量控制是為了控制發送⽅發送速率，保證接收⽅來得及接收。 接收⽅發送的確認報⽂中的窗⼝字段可以⽤來控制發送⽅窗⼝⼤⼩，從⽽影響發送⽅的發送速率。將窗⼝字段設置為 0，則發送⽅不能發送數據。發送窗口的大小由擁塞窗口和接收窗口的較小值決定。
2.9 TCP 的擁塞控制?
所謂“擁塞”指的是，在某段時間，網絡中某一資源的需求超過了該資源能提供的可用部分，使得網絡性能發生變化的情況。擁塞控制有四種方法：慢開始、擁塞避免、快重傳、快恢復。
為了進行擁塞控制，TCP發送方會維持一個叫擁塞窗口（cwnd）的狀態變量。為避免一開始就將大量數據注入網絡引起網絡擁塞，因此在開始傳數據時，使用慢開始算法，它會從小到大的逐漸增大擁塞窗口的數值，cwnd初始值為1，每經過一個輪次，cwnd就加倍；直到cwnd >= sssthresh（設定的窗口閾值），就轉而執行擁塞避免算法，每經過一個輪次，cwnd加1；在傳輸過程中，如果遇到了超時重傳，判斷網絡出現了擁塞，則將ssthresh閾值設定為原來的一半，將擁塞窗口cwnd設置為1，重新開始使用慢開始算法。如果遇到了3-ACK（收到3個重復確認）的情況，則判定分組丟失，使用快重傳算法，重傳丟失報文，並轉而執行快恢復算法， 將ssthresh閾值設定為原來的一半，將擁塞窗口cwnd的值設置為ssthresh閾值，繼續執行擁塞避免算法。快重傳算法：如果在超時重傳定時器溢出之前，接收到連續的三個重復冗余ACK，發送端便知曉哪個報文段在傳輸過程中丟失了，於是重發該報文段，不需要等待超時重傳定時器溢出再發送該報文。
2.10 TCP的長連接和短連接
7.1. TCP短連接
模擬一下TCP短連接的情況：client向server發起連接請求，server接到請求，然后雙方建立連接。client向server發送消息，server回應client，然后一次請求就完成了。這時候雙方任意都可以發起close操作，不過一般都是client先發起close操作。上述可知，短連接一般只會在 client/server間傳遞一次請求操作。
短連接的優點是：管理起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段。
7.2. TCP長連接
我們再模擬一下長連接的情況：client向server發起連接，server接受client連接，雙方建立連接，client與server完成一次請求后，它們之間的連接並不會主動關閉，后續的讀寫操作會繼續使用這個連接。
7.3. 長連接和短連接的優點和缺點
由上可以看出，長連接可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間。對於頻繁請求資源的客戶來說，較適用長連接。不過這里存在一個問題，存活功能的探測周期太長，還有就是它只是探測TCP連接的存活，屬於比較斯文的做法，遇到惡意的連接時，保活功能就不夠使了。在長連接的應用場景下，client端一般不會主動關閉它們之間的連接，Client與server之間的連接如果一直不關閉的話，會存在一個問題，隨着客戶端連接越來越多，server早晚有扛不住的時候，這時候server端需要采取一些策略，如關閉一些長時間沒有讀寫事件發生的連接，這樣可 以避免一些惡意連接導致server端服務受損；如果條件再允許就可以以客戶端機器為顆粒度，限制每個客戶端的最大長連接數，這樣可以完全避免某個蛋疼的客戶端連累后端服務。
短連接對於服務器來說管理較為簡單，存在的連接都是有用的連接，不需要額外的控制手段。但如果客戶請求頻繁，將在TCP的建立和關閉操作上浪費時間和帶寬。
長連接和短連接的產生在於client和server采取的關閉策略，具體的應用場景采用具體的策略，沒有十全十美的選擇，只有合適的選擇。
7.4. 長連接短連接操作過程
短連接的操作步驟是：
建立連接——數據傳輸——關閉連接...建立連接——數據傳輸——關閉連接
長連接的操作步驟是：
建立連接——數據傳輸...（保持連接）...數據傳輸——關閉連接
7.5. 什么時候用長連接，短連接？
長連接多用於操作頻繁，點對點的通訊，而且連接數不能太多情況。每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那么處理速度會降低很多，所以每個操作完后都不斷開，次處理時直接發送數據包就OK了，不用建立TCP連接。例如：數據庫的連接用長連接， 如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創建也是對資源的浪費。
而像WEB網站的http服務一般都用短鏈接，因為長連接對於服務端來說會耗費一定的資源，而像WEB網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都占用一個連接的話，那可想而知吧。所以並發量大，但每個用戶無需頻繁操作情況下需用短連好。
3. HTTP
3.1 地址欄輸入URL的過程
總體來說分為以下幾個過程:
3.2 簡述HTTP協議
HTTP協議是超文本傳輸協議。它是基於TCP協議的應用層協議，即客服端和服務器段進行數據傳輸的一種規則。HTTP協議本身是一種無狀態的協議。
3.3 簡述cookie
HTTP協議本身是無狀態的，為了使其處理更加復雜的邏輯，在HTTP1.1中引入了Cookie來保存狀態信息。Cookie是由服務器端產生的，再發送給客戶端保存，當客服端再次訪問的時候，服務器根據cookie辨識客戶端是那個，以此可以做個性化推送，免賬號密碼登錄等。
3.4 簡述session
Session用於標記特定客戶端信息，存在服務器的一個文件里。一般客戶端帶Cookie對服務器進行訪問，可以通過cookie中的session id 從整個session中查詢服務器記錄的關於客戶端的信息。
3.5 簡述Cookie 和 Session的區別
Cookie 數據保存在客戶端(瀏覽器端)，一般用來保存用戶信息，Session 數據保存在服務器端，主要通過服務器端記錄用戶的狀態。
相對來說** Session 安全性更⾼**。如果要在Cookie 中存儲⼀些敏感信息，不要直接寫⼊ Cookie 中，最好能將 Cookie 信息加密然后使⽤到的時候再去服務器端解密。
3.6 HTTP1.0 和HTTP1.1的主要區別是什么？
- ⻓連接 : 在HTTP/1.0中，默認使⽤的是短連接，也就是說每次請求都要重新建⽴⼀次連接。HTTP 是基於TCP/IP協議的,每⼀次建⽴或者斷開連接都需要三次握⼿四次揮⼿的開銷，如果每次請求都要這樣的話，開銷會⽐較⼤。因此最好能維持⼀個⻓連接，可以⽤個⻓連接來發多個請求。HTTP 1.1起，默認使⽤⻓連接 ,默認開啟Connection： keep-alive。 HTTP/1.1的持續連接有⾮流⽔線⽅式和流⽔線⽅式 。流⽔線⽅式是客戶在收到HTTP的響應報⽂之前就能接着發送新的請求報⽂。與之相對應的⾮流⽔線⽅式是客戶在收到前⼀個響應后才能發送下⼀個請求。
- 錯誤狀態響應碼 :在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發⽣沖突；410（Gone）表示服務器上的某個資源被永久性的刪除。
- 緩存處理 :在HTTP1.0中主要使⽤header⾥的If-Modified-Since,Expires來做為緩存判斷的標准，HTTP1.1則引⼊了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match,If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
- 帶寬優化及⽹絡連接的使⽤ :HTTP1.0中，存在⼀些浪費帶寬的現象，例如客戶端只是需要某個對象的⼀部分，⽽服務器卻將整個對象送過來了，並且不⽀持斷點續傳功能，HTTP1.1則在請求頭引⼊了range頭域，它允許只請求資源的某個部分，即返回碼是206（PartialContent），這樣就⽅便了開發者⾃由的選擇以便於充分利⽤帶寬和連接。
3.7 簡述http2.0的改進
**提出多路復用**。多路復用前，文件時串行傳輸的，請求a文件，b文件只能等待，並且連接數過多。引入多路復用，a文件b文件可以**同時傳輸。 **<br />**引入了二進制數據幀**。其中幀對數據進行順序標識，有了序列id，服務器就可以進行並行傳輸數據。
3.8 HTTP 和 HTTPS 的區別,HTTPS是如何實現的？
- 端⼝ ：HTTP的URL由“http://”起始且默認使⽤端⼝80，⽽HTTPS的URL由“https://”起始且默認使⽤端⼝443。
- 安全性和資源消耗： HTTP協議運⾏在TCP之上，所有傳輸的內容都是明⽂，客戶端和服務器端都⽆法驗證對⽅的身份。HTTPS是運⾏在SSL/TLS之上的HTTP協議，SSL/TLS 運⾏在TCP之上。所有傳輸的內容都經過加密，加密采⽤對稱加密，但對稱加密的密鑰⽤服務器⽅的證書進⾏了⾮對稱加密。所以說，HTTP 安全性沒有 HTTPS⾼，但是 HTTPS ⽐HTTP耗費更多服務器資源。
- ** HTTPS的實現過程（SSL/TLS握手過程）**
- 瀏覽器將支持的加密算法信息發給服務器
- 服務器選擇一套瀏覽器支持的加密算法，以證書的形式回發給瀏覽器
- 客戶端(SSL/TLS)解析證書驗證證書合法性，生成對稱加密的密鑰，我們將該密鑰稱之為client key，即客戶端密鑰，用服務器的公鑰對客戶端密鑰進行非對稱加密。
- 客戶端會發起HTTPS中的第二個HTTP請求，將加密之后的客戶端對稱密鑰發送給服務器
- 服務器接收到客戶端發來的密文之后，會用自己的私鑰對其進行非對稱解密，解密之后的明文就是客戶端密鑰，然后用客戶端密鑰對數據進行對稱加密，這樣數據就變成了密文。
- 服務器將加密后的密文發送給客戶端
- 客戶端收到服務器發送來的密文，用客戶端密鑰對其進行對稱解密，得到服務器發送的數據。這樣HTTPS中的第二個HTTP請求結束，整個HTTPS傳輸完成
3.9 服務器返回常見狀態碼及其意義
- 1XX: 表示接收的信息正在處理
- 2XX: **表示正常處理完畢 **
- 200 OK //客戶端請求成功
- 3XX: 重定向--要完成請求必須進行更進一步的操作
- 301 永久性重定向，
- 302 臨時性重定向
- 304：資源沒有修改，用之前的緩存就行
- 4XX: 客戶端錯誤--請求有語法錯誤或請求無法實現
- 400 Bad Request 客戶端請求的報文有誤。
- 401 Unauthorized 請求未經授權。
- 403 Forbidden 服務器禁止范圍資源。
- 404 Not Found 請求的資源在服務器上不存在或未找到。
- 5XX: 服務器端錯誤--服務器未能實現合法的請求
3.10 常用協議端口號
21: ftp–文件傳輸協議（FTP）
25: smtp–簡單郵件傳輸協議（SMTP）
53： dns–域名服務
80: http–超文本傳輸協議
443： https
8080：tomcat
110: pop3–郵局協議版本3
3.11 GET和POST的區別
GET和POST本質上就是TCP連接。一般在使用的時候，get方法將參數放在url中，post將參數放在request body當中。但是他們本質的區別（？並不是這樣）：GET產生一個TCP數據包；POST產生兩個TCP數據包。
Get方法：把http header和data放在一起發送，服務器返回200.
Post方法：瀏覽器先發http header，服務器返回100 continue，瀏覽器再發送data，服務器返回200
3.12 URI和URL的區別是什么？
- URI(Uniform Resource Identifier) 是統⼀資源標志符，可以唯⼀標識⼀個資源。
- URL(Uniform Resource Location) 是統⼀資源定位符，可以提供該資源的路徑。它是⼀種具體的 URI，即 URL 可以⽤來標識⼀個資源，⽽且還指明了如何 locate 這個資源。
- URI的作⽤像身份證號⼀樣，URL的作⽤更像家庭住址⼀樣。URL是⼀種具體的URI，它不僅唯⼀標識資源，⽽且還提供了定位該資源的信息。
4. ARP協議原理
分兩步：
- 本機中緩存的ARP列表中存儲了ip mac的 映射關系 查得到則直接得到目標主機的mac地址 查不到轉2 。
- 源主機在其本地網段 發送arp請求的廣播包 若該網段存在目標主機 則目標主機會回發一個ARP響應包 若收不到arp相應 則說明查找失敗 。
5. DNS（域名解析協議）
5.1 簡述DNS協議
DNS協議是基於UDP的應用層協議，它的功能是根據用戶輸入的域名，解析出該域名對應的IP地址，從而給客戶端進行訪問。
5.2 DNS域名解析過程
迭代查詢：
① 請求發起后，游覽器首先會解析這個域名，首先它會查看本地硬盤的 hosts 文件，看看其中有沒有和這個域名對應的規則，如果有的話就直接使用 hosts 文件里面的 ip 地址。
② 如果在本地的 hosts 文件沒有能夠找到對應的 ip 地址，瀏覽器會發出一個 DNS請求到本地DNS(域名分布系統)服務器 。本地DNS服務器一般都是你的網絡接入服務器商提供，比如中國電信，中國移動。
③ 查詢你輸入的網址的DNS請求到達本地DNS服務器之后，本地DNS服務器會首先查詢它的緩存記錄，如果緩存中有此條記錄，就可以直接返回結果，此過程是遞歸的方式進行查詢。如果沒有，本地DNS服務器還要向DNS根服務器進行查詢
④ 根DNS服務器沒有記錄具體的域名和IP地址的對應關系，而是告訴本地DNS服務器，你可以到那個頂級域服務器上去繼續查詢，並給出頂級域服務器的地址。這種過程是迭代的過程
⑤ 本地DNS服務器繼續向頂級域服務器發出請求，頂級域服務器收到請求之后，也不會直接返回域名和IP地址的對應關系，而是告訴本地DNS服務器，你應該去找那個權限域名服務器
⑥ 最后，本地DNS服務器向權限域名服務器發出請求，這時就能收到一個域名和IP地址對應關系，本地DNS服務器不僅要把IP地址返回給用戶電腦，還要把這個對應關系保存在緩存中，以備下次別的用戶查詢時，可以直接返回結果，加快網絡訪問。