計算機網(wǎng)絡(luò)

什么是三次握手 (three-way handshake)？

三次握手
  • 第一次握手：Client 將 SYN 置1，隨機產(chǎn)生一個初始序列號 seq 發(fā)送給 Server，進入 SYN_SENT 狀態(tài)；
  • 第二次握手：Server 收到 Client 的 SYN=1 之后，知道客戶端請求建立連接，將自己的 SYN 置1，ACK 置1，產(chǎn)生一個 acknowledge number=sequence number+1，并隨機產(chǎn)生一個自己的初始序列號，發(fā)送給客戶端；進入 SYN_RCVD 狀態(tài)；
  • 第三次握手：客戶端檢查 acknowledge number 是否為序列號+1，ACK 是否為1，檢查正確之后將自己的 ACK 置為1，產(chǎn)生一個 acknowledge number=服務(wù)器發(fā)的序列號+1，發(fā)送給服務(wù)器；進入 ESTABLISHED 狀態(tài)；服務(wù)器檢查 ACK 為1和 acknowledge number 為序列號+1之后，也進入 ESTABLISHED 狀態(tài)；完成三次握手，連接建立。

TCP 建立連接可以兩次握手嗎？為什么?

不可以。有兩個原因：
首先，可能會出現(xiàn)已失效的連接請求報文段又傳到了服務(wù)器端。

client 發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡(luò)結(jié)點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達 server。本來這是一個早已失效的報文段。但 server 收到此失效的連接請求報文段后，就誤認為是 client 再次發(fā)出的一個新的連接請求。于是就向 client 發(fā)出確認報文段，同意建立連接。假設(shè)不采用 “三次握手”，那么只要 server 發(fā)出確認，新的連接就建立了。由于現(xiàn)在 client 并沒有發(fā)出建立連接的請求，因此不會理睬 server 的確認，也不會向 server 發(fā)送數(shù)據(jù)。但 server 卻以為新的運輸連接已經(jīng)建立，并一直等待 client 發(fā)來數(shù)據(jù)。這樣，server 的很多資源就白白浪費掉了。采用 “三次握手” 的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client 不會向 server 的確認發(fā)出確認。server 由于收不到確認，就知道 client 并沒有要求建立連接。

其次，兩次握手無法保證 client 正確接收第二次握手的報文（server 無法確認 client 是否收到），也無法保證 client 和 server 之間成功互換初始序列號。

可以采用四次握手嗎？為什么？

可以。但是會降低傳輸?shù)男省?/p>

四次握手是指：第二次握手：Server 只發(fā)送 ACK 和 acknowledge number；而 Server 的 SYN 和初始序列號在第三次握手時發(fā)送；原來協(xié)議中的第三次握手變?yōu)榈谒拇挝帐?。出于?yōu)化目的，四次握手中的二、三可以合并。

第三次握手中，如果客戶端的 ACK 未送達服務(wù)器，會怎樣？

Server 端：

由于 Server 沒有收到 ACK 確認，因此會重發(fā)之前的 SYN+ACK（默認重發(fā)五次，之后自動關(guān)閉連接進入 CLOSED 狀態(tài)），Client 收到后會重新傳 ACK 給 Server。

Client 端，兩種情況：

  1. 在 Server 進行超時重發(fā)的過程中，如果 Client 向服務(wù)器發(fā)送數(shù)據(jù)，數(shù)據(jù)頭部的 ACK 是為1的，所以服務(wù)器收到數(shù)據(jù)之后會讀取 ACK number，進入 ESTABLISHED 狀態(tài)
  2. 在 Server 進入 CLOSED 狀態(tài)之后，如果 Client 向服務(wù)器發(fā)送數(shù)據(jù)，服務(wù)器會以 RST 包應(yīng)答。
如果已經(jīng)建立了連接，但客戶端出現(xiàn)了故障怎么辦？

服務(wù)器每收到一次客戶端的請求后都會重新復(fù)位一個計時器，時間通常是設(shè)置為2小時，若兩小時還沒有收到客戶端的任何數(shù)據(jù)，服務(wù)器就會發(fā)送一個探測報文段，以后每隔75秒鐘發(fā)送一次。若一連發(fā)送10個探測報文仍然沒反應(yīng)，服務(wù)器就認為客戶端出了故障，接著就關(guān)閉連接。

初始序列號是什么？

TCP 連接的一方 A，隨機選擇一個32位的序列號（Sequence Number）作為發(fā)送數(shù)據(jù)的初始序列號（Initial Sequence Number，ISN），比如為1000，以該序列號為原點，對要傳送的數(shù)據(jù)進行編號：1001、1002...三次握手時，把這個初始序列號傳送給另一方 B，以便在傳輸數(shù)據(jù)時，B 可以確認什么樣的數(shù)據(jù)編號是合法的；同時在進行數(shù)據(jù)傳輸時，A 還可以確認 B 收到的每一個字節(jié)，如果 A 收到了 B 的確認編號（acknowledge number）是2001，就說明編號為1001-2000的數(shù)據(jù)已經(jīng)被 B 成功接受。

什么是四次揮手？

四次揮手
  • 第一次揮手：Client 將 FIN 置為1，發(fā)送一個序列號 seq 給 Server；進入 F IN_WAIT_1 狀態(tài)；
  • 第二次揮手：Server 收到 FIN 之后，發(fā)送一個 ACK=1，acknowledge number=收到的序列號+1；進入 CLOSE_WAIT 狀態(tài)。此時客戶端已經(jīng)沒有要發(fā)送的數(shù)據(jù)了，但仍可以接受服務(wù)器發(fā)來的數(shù)據(jù)。
  • 第三次揮手：Server 將 FIN 置1，發(fā)送一個序列號給 Client；進入 LAST_ACK 狀態(tài)；
  • 第四次揮手：Client 收到服務(wù)器的 FIN 后，進入 TIME_WAIT 狀態(tài)；接著將 ACK 置1，發(fā)送一個 acknowledge number=序列號+1 給服務(wù)器；服務(wù)器收到后，確認 acknowledge number 后，變?yōu)?CLOSED 狀態(tài)，不再向客戶端發(fā)送數(shù)據(jù)?？蛻舳说却?2*MSL（報文段最長壽命）時間后，也進入 CLOSED 狀態(tài)。完成四次揮手。

為什么不能把服務(wù)器發(fā)送的 ACK 和 FIN 合并起來，變成三次揮手（CLOSE_WAIT 狀態(tài)意義是什么）？

因為服務(wù)器收到客戶端斷開連接的請求時，可能還有一些數(shù)據(jù)沒有發(fā)完，這時先回復(fù) ACK，表示接收到了斷開連接的請求。等到數(shù)據(jù)發(fā)完之后再發(fā) FIN，斷開服務(wù)器到客戶端的數(shù)據(jù)傳送。

如果第二次揮手時服務(wù)器的 ACK 沒有送達客戶端，會怎樣？

客戶端沒有收到 ACK 確認，會重新發(fā)送 FIN 請求。

客戶端 TIME_WAIT 狀態(tài)的意義是什么？

第四次揮手時，客戶端發(fā)送給服務(wù)器的 ACK 有可能丟失，TIME_WAIT 狀態(tài)就是用來重發(fā)可能丟失的 ACK 報文。如果 Server 沒有收到 ACK，就會重發(fā) FIN，如果 Client 在 2*MSL 的時間內(nèi)收到了 FIN，就會重新發(fā)送 ACK 并再次等待 2MSL，防止 Server 沒有收到 ACK 而不斷重發(fā) FIN。

MSL(Maximum Segment Lifetime)，指一個片段在網(wǎng)絡(luò)中最大的存活時間，2MSL 就是一個發(fā)送和一個回復(fù)所需的最大時間。如果直到 2MSL，Client 都沒有再次收到 FIN，那么 Client 推斷 ACK 已經(jīng)被成功接收，則結(jié)束 TCP 連接。

TCP 如何實現(xiàn)流量控制？

滑動窗口

使用滑動窗口協(xié)議實現(xiàn)流量控制。防止發(fā)送方發(fā)送速率太快，接收方緩存區(qū)不夠?qū)е乱绯?。接收方會維護一個接收窗口 receiver window（窗口大小單位是字節(jié)），接受窗口的大小是根據(jù)自己的資源情況動態(tài)調(diào)整的，在返回 ACK 時將接受窗口大小放在 TCP 報文中的窗口字段告知發(fā)送方。發(fā)送窗口的大小不能超過接受窗口的大小，只有當發(fā)送方發(fā)送并收到確認之后，才能將發(fā)送窗口右移。
發(fā)送窗口的上限為接受窗口和擁塞窗口中的較小值。接受窗口表明了接收方的接收能力，擁塞窗口表明了網(wǎng)絡(luò)的傳送能力。

滑動窗口

什么是零窗口（接收窗口為0時會怎樣）？

如果接收方?jīng)]有能力接收數(shù)據(jù)，就會將接收窗口設(shè)置為0，這時發(fā)送方必須暫停發(fā)送數(shù)據(jù)，但是會啟動一個持續(xù)計時器 (persistence timer)，到期后發(fā)送一個大小為1字節(jié)的探測數(shù)據(jù)包，以查看接收窗口狀態(tài)。如果接收方能夠接收數(shù)據(jù)，就會在返回的報文中更新接收窗口大小，恢復(fù)數(shù)據(jù)傳送。

TCP 的擁塞控制是怎么實現(xiàn)的？

擁塞控制

擁塞控制主要由四個算法組成：慢啟動（Slow Start）、擁塞避免（Congestion voidance）、快重傳 （Fast Retransmit）、快恢復(fù)（Fast Recovery）

  1. 慢啟動：剛開始發(fā)送數(shù)據(jù)時，先把擁塞窗口（congestion window）設(shè)置為一個最大報文段 MSS 的數(shù)值，每收到一個新的確認報文之后，就把擁塞窗口加1個 MSS。這樣每經(jīng)過一個傳輸輪次（或者說是每經(jīng)過一個往返時間 RTT），擁塞窗口的大小就會加倍


    slow start

  2. 擁塞避免：當擁塞窗口的大小達到慢開始門限 (slow start threshold) 時，開始執(zhí)行擁塞避免算法，擁塞窗口大小不再指數(shù)增加，而是線性增加，即每經(jīng)過一個傳輸輪次只增加1 MSS.

    無論在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞（其根據(jù)就是沒有收到確認），就要把慢開始門限 ssthresh 設(shè)置為出現(xiàn)擁塞時的發(fā)送方窗口值的一半（但不能小于2）。然后把擁塞窗口 cwnd 重新設(shè)置為1，執(zhí)行慢開始算法。（這是不使用快重傳的情況）

  3. 快重傳：快重傳要求接收方在收到一個失序的報文段后就立即發(fā)出重復(fù)確認（為的是使發(fā)送方及早知道有報文段沒有到達對方）而不要等到自己發(fā)送數(shù)據(jù)時捎帶確認。快重傳算法規(guī)定，發(fā)送方只要一連收到三個重復(fù)確認就應(yīng)當立即重傳對方尚未收到的報文段，而不必繼續(xù)等待設(shè)置的重傳計時器時間到期。

    快重傳

  4. 快恢復(fù)：當發(fā)送方連續(xù)收到三個重復(fù)確認時，就把慢開始門限減半，然后執(zhí)行擁塞避免算法。不執(zhí)行慢開始算法的原因：因為如果網(wǎng)絡(luò)出現(xiàn)擁塞的話就不會收到好幾個重復(fù)的確認，所以發(fā)送方認為現(xiàn)在網(wǎng)絡(luò)可能沒有出現(xiàn)擁塞。
    也有的快重傳是把開始時的擁塞窗口 cwnd 值再增大一點，即等于 ssthresh + 3*MSS 。這樣做的理由是：既然發(fā)送方收到三個重復(fù)的確認，就表明有三個分組已經(jīng)離開了網(wǎng)絡(luò)。這三個分組不再消耗網(wǎng)絡(luò)的資源而是停留在接收方的緩存中?？梢姮F(xiàn)在網(wǎng)絡(luò)中減少了三個分組。因此可以適當把擁塞窗口擴大些。

TCP 如何最大利用帶寬？

TCP 速率受到三個因素影響

  • 窗口：即滑動窗口大小，見TCP 如何實現(xiàn)流量控制？
  • 帶寬：這里帶寬是指單位時間內(nèi)從發(fā)送端到接收端所能通過的“最高數(shù)據(jù)率”，是一種硬件限制。TCP 發(fā)送端和接收端的數(shù)據(jù)傳輸數(shù)不可能超過兩點間的帶寬限制。發(fā)送端和接收端之間帶寬取所通過線路的帶寬最小值（如通過互聯(lián)網(wǎng)連接）。
  • RTT：即 Round Trip Time，表示從發(fā)送端到接收端的一去一回需要的時間，TCP 在數(shù)據(jù)傳輸過程中會對 RTT 進行采樣（即對發(fā)送的數(shù)據(jù)包及其 ACK 的時間差進行測量，并根據(jù)測量值更新 RTT 值），TCP 根據(jù)得到的 RTT 值更新 RTO 值，即 Retransmission TimeOut，就是重傳間隔，發(fā)送端對每個發(fā)出的數(shù)據(jù)包進行計時，如果在 RTO 時間內(nèi)沒有收到所發(fā)出的數(shù)據(jù)包的對應(yīng) ACK，則任務(wù)數(shù)據(jù)包丟失，將重傳數(shù)據(jù)。一般 RTO 值都比采樣得到的 RTT 值要大。

帶寬時延乘積
帶寬時延乘積=帶寬*RTT，實際上等于發(fā)送端到接收端單向通道的數(shù)據(jù)容積的兩倍，這里單向通道的數(shù)據(jù)容積可以這樣來理解，單向通道看成是一條單行道馬路，帶寬就是馬路的車道數(shù)，路上跑的汽車就是數(shù)據(jù)（不過這里所有汽車的速率都是一樣的，且不會有人想超車，大家齊頭并進），那么單向通道的數(shù)據(jù)容積就是這條單行道上擺滿車，一共可以擺多少輛。帶寬就是馬路的車道數(shù)，帶寬數(shù)乘以單向通道的數(shù)據(jù)容積就是路面上所能容納的全部數(shù)據(jù)量。當路面上已經(jīng)擺滿的時候，就不能再往里面放了。

前面已經(jīng)說過了，TCP 發(fā)送數(shù)據(jù)時受滑動窗口的限制，當 TCP 將滑動窗口中的數(shù)據(jù)都發(fā)出后，在收到第一個 ACK 之前，滑動窗口大小是0，不能再發(fā)送數(shù)據(jù)了，必須等待 ACK 包使滑動窗口移動。那么在理想情況下，ACK 包應(yīng)該在什么時候到達呢？顯然，就是在數(shù)據(jù)發(fā)出后的 RTT 時間后，ACK 包到達。

現(xiàn)在再考慮帶寬限制，前面說過當馬路上擺滿車的時候，就無法再往里放車了，同理，TCP 發(fā)送端在時間內(nèi)，能往通道上放的最大數(shù)據(jù)量則就受到容積限制，即此時速率限制來源于帶寬限制。

在我們平時生活中使用的寬帶網(wǎng)絡(luò)，ADSL 等環(huán)境下，因為帶寬都比較小，再加上網(wǎng)絡(luò)情況比較復(fù)雜，擁塞情況比較常見，所以這些網(wǎng)絡(luò)環(huán)境下，TCP 速率的主要限制因素在于帶寬，丟包率等。長肥管道一般不太常見，多見于一些單位使用的專線網(wǎng)絡(luò)，在這些網(wǎng)絡(luò)中速率的主要限制因素就是窗口大小了，這也是傳統(tǒng) TCP 在這些網(wǎng)絡(luò)環(huán)境中不能充分利用帶寬的原因所在（因為傳統(tǒng) TCP 的窗口大小是用2字節(jié)表示的，所以最大只有65535（不考慮窗口擴大選項）），除了專線網(wǎng)絡(luò)外，隨著網(wǎng)絡(luò)硬件技術(shù)的發(fā)展，萬兆交換機的出現(xiàn)，局域網(wǎng)中也可能會出現(xiàn)帶寬時延乘積較大的情況。

TCP 與 UDP 的區(qū)別

  1. TCP 是面向連接的，UDP 是無連接的；

    UDP 發(fā)送數(shù)據(jù)之前不需要建立連接

  2. TCP 是可靠的，UDP 不可靠；

    UDP 接收方收到報文后，不需要給出任何確認

  3. TCP 只支持點對點通信，UDP 支持一對一、一對多、多對一、多對多；
  4. TCP 是面向字節(jié)流的，UDP 是面向報文的；

    面向字節(jié)流是指發(fā)送數(shù)據(jù)時以字節(jié)為單位，一個數(shù)據(jù)包可以拆分成若干組進行發(fā)送，而 UDP 一個報文只能一次發(fā)完。

  5. TCP 有擁塞控制機制，UDP 沒有。網(wǎng)絡(luò)出現(xiàn)的擁塞不會使源主機的發(fā)送速率降低，這對某些實時應(yīng)用是很重要的，比如媒體通信，游戲；
  6. TCP 首部開銷（20字節(jié)）比 UDP 首部開銷（8字節(jié)）要大
  7. UDP 的主機不需要維持復(fù)雜的連接狀態(tài)表

什么時候選擇 TCP，什么時候選 UDP？

對某些實時性要求比較高的情況，選擇 UDP，比如游戲，媒體通信，實時視頻流（直播），即使出現(xiàn)傳輸錯誤也可以容忍；其它大部分情況下，HTTP 都是用 TCP，因為要求傳輸?shù)膬?nèi)容可靠，不出現(xiàn)丟失

HTTP 可以使用 UDP 嗎？

HTTP 不可以使用 UDP，HTTP 需要基于可靠的傳輸協(xié)議，而 UDP 不可靠

注：http 3.0 使用 udp 實現(xiàn)
https://zh.wikipedia.org/wiki/HTTP/3

面向連接和無連接的區(qū)別

無連接的網(wǎng)絡(luò)服務(wù)（數(shù)據(jù)報服務(wù)）-- 面向連接的網(wǎng)絡(luò)服務(wù)（虛電路服務(wù)）
虛電路服務(wù)：首先建立連接，所有的數(shù)據(jù)包經(jīng)過相同的路徑，服務(wù)質(zhì)量有較好的保證；
數(shù)據(jù)報服務(wù)：每個數(shù)據(jù)包含目的地址，數(shù)據(jù)路由相互獨立（路徑可能變化）；網(wǎng)絡(luò)盡最大努力交付數(shù)據(jù)，但不保證不丟失、不保證先后順序、不保證在時限內(nèi)交付；網(wǎng)絡(luò)發(fā)生擁塞時，可能會將一些分組丟棄；


20191201081919108_30577.png

TCP 如何保證傳輸?shù)目煽啃?/h3>
  1. 數(shù)據(jù)包校驗
  2. 對失序數(shù)據(jù)包重新排序（TCP 報文具有序列號）
  3. 丟棄重復(fù)數(shù)據(jù)
  4. 應(yīng)答機制：接收方收到數(shù)據(jù)之后，會發(fā)送一個確認（通常延遲幾分之一秒）；
  5. 超時重發(fā)：發(fā)送方發(fā)出數(shù)據(jù)之后，啟動一個定時器，超時未收到接收方的確認，則重新發(fā)送這個數(shù)據(jù)；
  6. 流量控制：確保接收端能夠接收發(fā)送方的數(shù)據(jù)而不會緩沖區(qū)溢出

HTTP 和 HTTPS 有什么區(qū)別？

  1. 端口不同：HTTP 使用的是80端口，HTTPS 使用443端口；
  2. HTTP（超文本傳輸協(xié)議）信息是明文傳輸，HTTPS 運行在 SSL(Secure Socket Layer)之上，添加了加密和認證機制，更加安全；
  3. HTTPS 由于加密解密會帶來更大的 CPU 和內(nèi)存開銷；
  4. HTTPS 通信需要證書，一般需要向證書頒發(fā)機構(gòu)（CA）購買

HTTPS 的連接過程？

  1. 客戶端向服務(wù)器發(fā)送請求，同時發(fā)送客戶端支持的一套加密規(guī)則（包括對稱加密、非對稱加密、摘要算法）；
  2. 服務(wù)器從中選出一組加密算法與 HASH 算法，并將自己的身份信息以證書的形式發(fā)回給瀏覽器。證書里面包含了網(wǎng)站地址，加密公鑰（用于非對稱加密），以及證書的頒發(fā)機構(gòu)等信息（證書中的私鑰只能用于服務(wù)器端進行解密）；
  3. 客戶端驗證服務(wù)器的合法性，包括：證書是否過期，CA 是否可靠，發(fā)行者證書的公鑰能否正確解開服務(wù)器證書的“發(fā)行者的數(shù)字簽名”，服務(wù)器證書上的域名是否和服務(wù)器的實際域名相匹配；
  4. 如果證書受信任，或者用戶接收了不受信任的證書，瀏覽器會生成一個隨機密鑰（用于對稱算法），并用服務(wù)器提供的公鑰加密（采用非對稱算法對密鑰加密）；使用 Hash 算法對握手消息進行摘要計算，并對摘要使用之前產(chǎn)生的密鑰加密（對稱算法）；將加密后的隨機密鑰和摘要一起發(fā)送給服務(wù)器；
  5. 服務(wù)器使用自己的私鑰解密，得到對稱加密的密鑰，用這個密鑰解密出 Hash 摘要值，并驗證握手消息是否一致；如果一致，服務(wù)器使用對稱加密的密鑰加密握手消息發(fā)給瀏覽器；
  6. 瀏覽器解密并驗證摘要，若一致，則握手結(jié)束。之后的數(shù)據(jù)傳送都使用對稱加密的密鑰進行加密

總結(jié)：非對稱加密算法用于在握手過程中加密生成的密碼；對稱加密算法用于對真正傳輸?shù)臄?shù)據(jù)進行加密；HASH 算法用于驗證數(shù)據(jù)的完整性。

輸入 www.baidu.com，怎么變成 https://www.baidu.com 的，怎么確定用 HTTP 還是 HTTPS？

你訪問的網(wǎng)站是如何自動切換到 HTTPS 的？

一種是原始的 302 跳轉(zhuǎn)，服務(wù)器把所有的 HTTP 流量跳轉(zhuǎn)到 HTTPS。但這樣有一個漏洞，就是中間人可能在第一次訪問站點的時候就劫持。
解決方法是引入 HSTS 機制，用戶瀏覽器在訪問站點的時候強制使用 HTTPS。

HTTPS 連接的時候，怎么確定收到的包是服務(wù)器發(fā)來的（中間人攻擊）？
  1. 驗證域名、有效期等信息是否正確。證書上都有包含這些信息，比較容易完成驗證；
  2. 判斷證書來源是否合法。每份簽發(fā)證書都可以根據(jù)驗證鏈查找到對應(yīng)的根證書，操作系統(tǒng)、瀏覽器會在本地存儲權(quán)威機構(gòu)的根證書，利用本地根證書可以對對應(yīng)機構(gòu)簽發(fā)證書完成來源驗證；
  3. 判斷證書是否被篡改。需要與 CA 服務(wù)器進行校驗；
  4. 判斷證書是否已吊銷。通過 CRL（Certificate Revocation List 證書注銷列表）和 OCSP（Online Certificate Status Protocol 在線證書狀態(tài)協(xié)議）實現(xiàn)，其中 OCSP 可用于第3步中以減少與 CA 服務(wù)器的交互，提高驗證效率
什么是對稱加密、非對稱加密？區(qū)別是什么？
  • 對稱加密：加密和解密采用相同的密鑰。如：DES、RC2、RC4
  • 非對稱加密：需要兩個密鑰：公鑰和私鑰。如果用公鑰加密，需要用私鑰才能解密。如：RSA
  • 區(qū)別：對稱加密速度更快，通常用于大量數(shù)據(jù)的加密；非對稱加密安全性更高（不需要傳送私鑰）
數(shù)字簽名、報文摘要的原理
  • 發(fā)送者 A 用私鑰進行簽名，接收者 B 用公鑰驗證簽名。因為除 A 外沒有人有私鑰，所以 B 相信簽名是來自 A。A 不可抵賴，B 也不能偽造報文。
  • 摘要算法: MD5、SHA

GET 與 POST 的區(qū)別？

  1. GET 是冪等的，即讀取同一個資源，總是得到相同的數(shù)據(jù)，POST 不是冪等的；
  2. GET 一般用于從服務(wù)器獲取資源，而 POST 有可能改變服務(wù)器上的資源；
  3. 請求形式上：GET 請求的數(shù)據(jù)附在 URL 之后，在 HTTP 請求頭中；POST 請求的數(shù)據(jù)在請求體中；
  4. 安全性：GET 請求可被緩存、收藏、保留到歷史記錄，且其請求數(shù)據(jù)明文出現(xiàn)在 URL 中。POST 的參數(shù)不會被保存，安全性相對較高；
  5. GET 只允許 ASCII 字符，POST 對數(shù)據(jù)類型沒有要求，也允許二進制數(shù)據(jù)；
  6. GET 的長度有限制（操作系統(tǒng)或者瀏覽器），而 POST 數(shù)據(jù)大小無限制

Session 與 Cookie 的區(qū)別？

Session 是服務(wù)器端保持狀態(tài)的方案，Cookie 是客戶端保持狀態(tài)的方案

Cookie保 存在客戶端本地，客戶端請求服務(wù)器時會將 Cookie 一起提交；Session 保存在服務(wù)端，通過檢索 Sessionid 查看狀態(tài)。保存 Sessionid 的方式可以采用 Cookie，如果禁用了Cookie，可以使用 URL 重寫機制（把會話 ID 保存在 URL 中）。

從輸入網(wǎng)址到獲得頁面的過程 (越詳細越好)？

  1. 瀏覽器查詢 DNS，獲取域名對應(yīng)的 IP 地址: 具體過程包括瀏覽器搜索自身的 DNS 緩存、搜索操作系統(tǒng)的 DNS 緩存、讀取本地的 Host 文件和向本地 DNS 服務(wù)器進行查詢等。對于向本地 DNS 服務(wù)器進行查詢，如果要查詢的域名包含在本地配置區(qū)域資源中，則返回解析結(jié)果給客戶機，完成域名解析(此解析具有權(quán)威性)；如果要查詢的域名不由本地 DNS 服務(wù)器區(qū)域解析，但該服務(wù)器已緩存了此網(wǎng)址映射關(guān)系，則調(diào)用這個 IP 地址映射，完成域名解析（此解析不具有權(quán)威性）。如果本地域名服務(wù)器并未緩存該網(wǎng)址映射關(guān)系，那么將根據(jù)其設(shè)置發(fā)起遞歸查詢或者迭代查詢；
  2. 瀏覽器獲得域名對應(yīng)的 IP 地址以后，瀏覽器向服務(wù)器請求建立鏈接，發(fā)起三次握手；
  3. TCP/IP 鏈接建立起來后，瀏覽器向服務(wù)器發(fā)送 HTTP 請求；
  4. 服務(wù)器接收到這個請求，并根據(jù)路徑參數(shù)映射到特定的請求處理器進行處理，并將處理結(jié)果及相應(yīng)的視圖返回給瀏覽器；
  5. 瀏覽器解析并渲染視圖，若遇到對 js 文件、css 文件及圖片等靜態(tài)資源的引用，則重復(fù)上述步驟并向服務(wù)器請求這些資源；
  6. 瀏覽器根據(jù)其請求到的資源、數(shù)據(jù)渲染頁面，最終向用戶呈現(xiàn)一個完整的頁面。

HTTP 請求有哪些常見狀態(tài)碼？

  1. 2xx狀態(tài)碼：操作成功。200 OK
  2. 3xx狀態(tài)碼：重定向。301 永久重定向；302暫時重定向
  3. 4xx狀態(tài)碼：客戶端錯誤。400 Bad Request；401 Unauthorized；403 Forbidden；404 Not Found；
  4. 5xx狀態(tài)碼：服務(wù)端錯誤。500服務(wù)器內(nèi)部錯誤；501服務(wù)不可用

什么是 RIP(Routing Information Protocol, 距離矢量路由協(xié)議)? 算法是什么？

每個路由器維護一張表，記錄該路由器到其它網(wǎng)絡(luò)的”跳數(shù)“，路由器到與其直接連接的網(wǎng)絡(luò)的跳數(shù)是1，每多經(jīng)過一個路由器跳數(shù)就加1；更新該表時和相鄰路由器交換路由信息；路由器允許一個路徑最多包含15個路由器，如果跳數(shù)為16，則不可達。交付數(shù)據(jù)報時優(yōu)先選取距離最短的路徑。

（PS：RIP 是應(yīng)用層協(xié)議：https://www.zhihu.com/question/19645407）

  • 實現(xiàn)簡單，開銷小
  • 隨著網(wǎng)絡(luò)規(guī)模擴大開銷也會增大；
  • 最大距離為15，限制了網(wǎng)絡(luò)的規(guī)模；
  • 當網(wǎng)絡(luò)出現(xiàn)故障時，要經(jīng)過較長的時間才能將此信息傳遞到所有路由器

計算機網(wǎng)絡(luò)體系結(jié)構(gòu)

計算機網(wǎng)絡(luò)體系結(jié)構(gòu)
  • Physical, Data Link, Network, Transport, Application
  • 應(yīng)用層：常見協(xié)議：
    • FTP (21端口)：文件傳輸協(xié)議
    • SSH (22端口)：遠程登陸
    • TELNET (23端口)：遠程登錄
    • SMTP (25端口)：發(fā)送郵件
    • POP3 (110端口)：接收郵件
    • HTTP (80端口)：超文本傳輸協(xié)議
    • DNS (53端口)：運行在 UDP 上，域名解析服務(wù)
  • 傳輸層：TCP/UDP
  • 網(wǎng)絡(luò)層：IP、ARP、NAT、RIP...

路由器、交換機位于哪一層？

  • 路由器網(wǎng)絡(luò)層，根據(jù) IP 地址進行尋址；
  • 交換機數(shù)據(jù)鏈路層，根據(jù) MAC 地址進行尋址

IP 地址的分類？

IP address

路由器僅根據(jù)網(wǎng)絡(luò)號 net-id 來轉(zhuǎn)發(fā)分組，當分組到達目的網(wǎng)絡(luò)的路由器之后，再按照主機號 host-id 將分組交付給主機；同一網(wǎng)絡(luò)上的所有主機的網(wǎng)絡(luò)號相同。

什么叫劃分子網(wǎng)？

從主機號 host-id 借用若干個比特作為子網(wǎng)號 subnet-id；子網(wǎng)掩碼：網(wǎng)絡(luò)號和子網(wǎng)號都為1，主機號為0；數(shù)據(jù)報仍然先按照網(wǎng)絡(luò)號找到目的網(wǎng)絡(luò)，發(fā)送到路由器，路由器再按照網(wǎng)絡(luò)號和子網(wǎng)號找到目的子網(wǎng)：將子網(wǎng)掩碼與目標地址逐比特與操作，若結(jié)果為某個子網(wǎng)的網(wǎng)絡(luò)地址，則送到該子網(wǎng)。

什么是 ARP 協(xié)議 (Address Resolution Protocol)？

ARP 協(xié)議完成了 IP 地址與物理地址的映射。每一個主機都設(shè)有一個 ARP 高速緩存，里面有所在的局域網(wǎng)上的各主機和路由器的 IP 地址到硬件地址的映射表。當源主機要發(fā)送數(shù)據(jù)包到目的主機時，會先檢查自己的 ARP 高速緩存中有沒有目的主機的 MAC 地址，如果有，就直接將數(shù)據(jù)包發(fā)到這個 MAC 地址，如果沒有，就向所在的局域網(wǎng)發(fā)起一個 ARP 請求的廣播包（在發(fā)送自己的 ARP 請求時，同時會帶上自己的 IP 地址到硬件地址的映射），收到請求的主機檢查自己的 IP 地址和目的主機的 IP 地址是否一致，如果一致，則先保存源主機的映射到自己的 ARP 緩存，然后給源主機發(fā)送一個 ARP 響應(yīng)數(shù)據(jù)包。源主機收到響應(yīng)數(shù)據(jù)包之后，先添加目的主機的 IP 地址與 MAC 地址的映射，再進行數(shù)據(jù)傳送。如果源主機一直沒有收到響應(yīng)，表示 ARP 查詢失敗。
如果所要找的主機和源主機不在同一個局域網(wǎng)上，那么就要通過 ARP 找到一個位于本局域網(wǎng)上的某個路由器的硬件地址，然后把分組發(fā)送給這個路由器，讓這個路由器把分組轉(zhuǎn)發(fā)給下一個網(wǎng)絡(luò)。剩下的工作就由下一個網(wǎng)絡(luò)來做。

什么是 NAT (Network Address Translation, 網(wǎng)絡(luò)地址轉(zhuǎn)換)？

用于解決內(nèi)網(wǎng)中的主機要和因特網(wǎng)上的主機通信。由 NAT 路由器將主機的本地 IP 地址轉(zhuǎn)換為全球 IP 地址，分為靜態(tài)轉(zhuǎn)換（轉(zhuǎn)換得到的全球 IP 地址固定不變）和動態(tài) NAT 轉(zhuǎn)換。

參考

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容