內(nèi)容參考-帥地玩編程

1、為什么需要三次握手？兩次不行？

• 三次握手
  當面試官問你為什么需要有三次握手、三次握手的作用、講講三次握手的時候，我想很多人會這樣回答：
  首先很多人會先講下握手的過程：
  1、第一次握手：客戶端給服務器發(fā)送一個 SYN 報文。
  2、第二次握手：服務器收到 SYN 報文之后，會應答一個 SYN+ACK 報文。
  3、第三次握手：客戶端收到 SYN+ACK 報文之后，會回應一個 ACK 報文。
  4、服務器收到 ACK 報文之后，三次握手建立完成。
  作用是為了確認雙方的接收與發(fā)送能力是否正常。
  這里我順便解釋一下為啥只有三次握手才能確認雙方的接受與發(fā)送能力是否正常，而兩次卻不可以：
  第一次握手：客戶端發(fā)送網(wǎng)絡包，服務端收到了。這樣服務端就能得出結(jié)論：客戶端的發(fā)送能力、服務端的接收能力是正常的。
  第二次握手：服務端發(fā)包，客戶端收到了。這樣客戶端就能得出結(jié)論：服務端的接收、發(fā)送能力，客戶端的接收、發(fā)送能力是正常的。不過此時服務器并不能確認客戶端的接收能力是否正常。
  第三次握手：客戶端發(fā)包，服務端收到了。這樣服務端就能得出結(jié)論：客戶端的接收、發(fā)送能力正常，服務器自己的發(fā)送、接收能力也正常。
  因此，需要三次握手才能確認雙方的接收與發(fā)送能力是否正常。
  這樣回答其實也是可以的，但我覺得，這個過程的我們應該要描述的更詳細一點，因為三次握手的過程中，雙方是由很多狀態(tài)的改變的，而這些狀態(tài)，也是面試官可能會問的點。所以我覺得在回答三次握手的時候，我們應該要描述的詳細一點，而且描述的詳細一點意味著可以扯久一點。加分的描述我覺得應該是這樣：
  剛開始客戶端處于 closed 的狀態(tài)，服務端處于 listen 狀態(tài)。然后
  1、第一次握手：客戶端給服務端發(fā)一個 SYN 報文，并指明客戶端的初始化序列號 ISN(c)。此時客戶端處于 SYN_Send 狀態(tài)。
  2、第二次握手：服務器收到客戶端的 SYN 報文之后，會以自己的 SYN 報文作為應答，并且也是指定了自己的初始化序列號 ISN(s)，同時會把客戶端的 ISN + 1 作為 ACK 的值，表示自己已經(jīng)收到了客戶端的 SYN，此時服務器處于 SYN_RCVD 的狀態(tài)。
  3、第三次握手：客戶端收到 SYN 報文之后，會發(fā)送一個 ACK 報文，當然，也是一樣把服務器的 ISN + 1 作為 ACK 的值，表示已經(jīng)收到了服務端的 SYN 報文，此時客戶端處于 established 狀態(tài)。
  4、服務器收到 ACK 報文之后，也處于 established 狀態(tài)，此時，雙方建立起了鏈接

• 三次握手的作用
  三次握手的作用也是有好多的，多記住幾個，保證不虧。例如：
  1、確認雙方的接受能力、發(fā)送能力是否正常。
  2、指定自己的初始化序列號，為后面的可靠傳送做準備。
  1、（ISN）是固定的嗎
  三次握手的一個重要功能是客戶端和服務端交換ISN(Initial Sequence Number), 以便讓對方知道接下來接收數(shù)據(jù)的時候如何按序列號組裝數(shù)據(jù)。
  如果ISN是固定的，攻擊者很容易猜出后續(xù)的確認號，因此 ISN 是動態(tài)生成的。
  2、什么是半連接隊列
  服務器第一次收到客戶端的 SYN 之后，就會處于 SYN_RCVD 狀態(tài)，此時雙方還沒有完全建立其連接，服務器會把此種狀態(tài)下請求連接放在一個隊列里，我們把這種隊列稱之為半連接隊列。當然還有一個全連接隊列，就是已經(jīng)完成三次握手，建立起連接的就會放在全連接隊列中。如果隊列滿了就有可能會出現(xiàn)丟包現(xiàn)象。
  這里在補充一點關于SYN-ACK 重傳次數(shù)的問題：　服務器發(fā)送完SYN－ACK包，如果未收到客戶確認包，服務器進行首次重傳，等待一段時間仍未收到客戶確認包，進行第二次重傳，如果重傳次數(shù)超 過系統(tǒng)規(guī)定的最大重傳次數(shù)，系統(tǒng)將該連接信息從半連接隊列中刪除。注意，每次重傳等待的時間不一定相同，一般會是指數(shù)增長，例如間隔時間為 1s, 2s, 4s, 8s,
  3、三次握手過程中可以攜帶數(shù)據(jù)嗎
  很多人可能會認為三次握手都不能攜帶數(shù)據(jù)，其實第三次握手的時候，是可以攜帶數(shù)據(jù)的。也就是說，第一次、第二次握手不可以攜帶數(shù)據(jù)，而第三次握手是可以攜帶數(shù)據(jù)的。
  為什么這樣呢？大家可以想一個問題，假如第一次握手可以攜帶數(shù)據(jù)的話，如果有人要惡意攻擊服務器，那他每次都在第一次握手中的 SYN 報文中放入大量的數(shù)據(jù)，因為攻擊者根本就不理服務器的接收、發(fā)送能力是否正常，然后瘋狂著重復發(fā) SYN 報文的話，這會讓服務器花費很多時間、內(nèi)存空間來接收這些報文。也就是說，第一次握手可以放數(shù)據(jù)的話，其中一個簡單的原因就是會讓服務器更加容易受到攻擊了。
  而對于第三次的話，此時客戶端已經(jīng)處于 established 狀態(tài)，也就是說，對于客戶端來說，他已經(jīng)建立起連接了，并且也已經(jīng)知道服務器的接收、發(fā)送能力是正常的了，所以能攜帶數(shù)據(jù)頁沒啥毛病。

2、為什么需要四次揮手？三次不行？

四次揮手也一樣，千萬不要對方一個 FIN 報文，我方一個 ACK 報文，再我方一個 FIN 報文，我方一個 ACK 報文。然后結(jié)束，最好是說的詳細一點，例如想下面這樣就差不多了，要把每個階段的狀態(tài)記好，我上次面試就被問了幾個了，呵呵。我答錯了，還以為自己答對了，當時還解釋的頭頭是道，呵呵。
剛開始雙方都處于 establised 狀態(tài)，假如是客戶端先發(fā)起關閉請求，則：
1、第一次揮手：客戶端發(fā)送一個 FIN 報文，報文中會指定一個序列號。此時客戶端處于FIN_WAIT1狀態(tài)。
2、第二次握手：服務端收到 FIN 之后，會發(fā)送 ACK 報文，且把客戶端的序列號值 + 1 作為 ACK 報文的序列號值，表明已經(jīng)收到客戶端的報文了，此時服務端處于 CLOSE_WAIT2狀態(tài)。
3、第三次揮手：如果服務端也想斷開連接了，和客戶端的第一次揮手一樣，發(fā)給 FIN 報文，且指定一個序列號。此時服務端處于 LAST_ACK 的狀態(tài)。
4、第四次揮手：客戶端收到 FIN 之后，一樣發(fā)送一個 ACK 報文作為應答，且把服務端的序列號值 + 1 作為自己 ACK 報文的序列號值，此時客戶端處于 TIME_WAIT 狀態(tài)。需要過一陣子以確保服務端收到自己的 ACK 報文之后才會進入 CLOSED 狀態(tài)
5、服務端收到 ACK 報文之后，就處于關閉連接了，處于 CLOSED 狀態(tài)。

這里特別需要主要的就是TIME_WAIT這個狀態(tài)了，這個是面試的高頻考點，就是要理解，為什么客戶端發(fā)送 ACK 之后不直接關閉，而是要等一陣子才關閉。這其中的原因就是，要確保服務器是否已經(jīng)收到了我們的 ACK 報文，如果沒有收到的話，服務器會重新發(fā) FIN 報文給客戶端，客戶端再次收到 FIN 報文之后，就知道之前的 ACK 報文丟失了，然后再次發(fā)送 ACK 報文。
至于 TIME_WAIT 持續(xù)的時間至少是一個報文的來回時間。一般會設置一個計時，如果過了這個計時沒有再次收到 FIN 報文，則代表對方成功就是 ACK 報文，此時處于 CLOSED 狀態(tài)。
這里我給出每個狀態(tài)所包含的含義，有興趣的可以看看。
LISTEN – 偵聽來自遠方TCP端口的連接請求；
SYN-SENT -在發(fā)送連接請求后等待匹配的連接請求；
SYN-RECEIVED – 在收到和發(fā)送一個連接請求后等待對連接請求的確認；

ESTABLISHED- 代表一個打開的連接，數(shù)據(jù)可以傳送給用戶；
FIN-WAIT-1 – 等待遠程TCP的連接中斷請求，或先前的連接中斷請求的確認；
FIN-WAIT-2 – 從遠程TCP等待連接中斷請求；
CLOSE-WAIT – 等待從本地用戶發(fā)來的連接中斷請求；
CLOSING -等待遠程TCP對連接中斷的確認；
LAST-ACK – 等待原來發(fā)向遠程TCP的連接中斷請求的確認；
TIME-WAIT -等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認；
CLOSED – 沒有任何連接狀態(tài)；

3、TCP與UDP有哪些區(qū)別？各自應用場景？

• TCP協(xié)議的主要特點
  （1）TCP是面向連接的運輸層協(xié)議；所謂面向連接就是雙方傳輸數(shù)據(jù)之前，必須先建立一條通道，例如三次握手就是建議通道的一個過程，而四次揮手則是結(jié)束銷毀通道的一個其中過程。
  （2）每一條TCP連接只能有兩個端點（即兩個套接字），只能是點對點的；
  （3）TCP提供可靠的傳輸服務。傳送的數(shù)據(jù)無差錯、不丟失、不重復、按序到達；
  （4）TCP提供全雙工通信。允許通信雙方的應用進程在任何時候都可以發(fā)送數(shù)據(jù)，因為兩端都設有發(fā)送緩存和接受緩存；
  （5）面向字節(jié)流。雖然應用程序與TCP交互是一次一個大小不等的數(shù)據(jù)塊，但TCP把這些數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流，它不保證接收方收到的數(shù)據(jù)塊和發(fā)送方發(fā)送的數(shù)據(jù)塊具有對應大小關系，例如，發(fā)送方應用程序交給發(fā)送方的TCP10個數(shù)據(jù)塊，但就受訪的TCP可能只用了4個數(shù)據(jù)塊久保收到的字節(jié)流交付給上層的應用程序，但字節(jié)流完全一樣。
• TCP的可靠性原理
  可靠傳輸有如下兩個特點:
  a.傳輸信道無差錯,保證傳輸數(shù)據(jù)正確;
  b.不管發(fā)送方以多快的速度發(fā)送數(shù)據(jù),接收方總是來得及處理收到的數(shù)據(jù);
  （1）首先，采用三次握手來建立TCP連接，四次握手來釋放TCP連接，從而保證建立的傳輸信道是可靠的。
  （2）其次，TCP采用了連續(xù)ARQ協(xié)議（回退N，Go-back-N；超時自動重傳）來保證數(shù)據(jù)傳輸?shù)恼_性，使用滑動窗口協(xié)議來保證接方能夠及時處理所接收到的數(shù)據(jù)，進行流量控制。
  （3）最后，TCP使用慢開始、擁塞避免、快重傳和快恢復來進行擁塞控制，避免網(wǎng)絡擁塞。
• UDP協(xié)議特點
  （１）UDP是無連接的傳輸層協(xié)議；
  （２）UDP使用盡最大努力交付，不保證可靠交付；
  （３）UDP是面向報文的，對應用層交下來的報文，不合并，不拆分，保留原報文的邊界；
  （４）UDP沒有擁塞控制，因此即使網(wǎng)絡出現(xiàn)擁塞也不會降低發(fā)送速率；
  （５）UDP支持一對一　一對多　多對多的交互通信；
  （６）UDP的首部開銷小，只有８字節(jié)．
• TCP和UDP的區(qū)別
  (1)TCP是可靠傳輸,UDP是不可靠傳輸;
  (2)TCP面向連接,UDP無連接;
  (3)TCP傳輸數(shù)據(jù)有序,UDP不保證數(shù)據(jù)的有序性;
  (4)TCP不保存數(shù)據(jù)邊界,UDP保留數(shù)據(jù)邊界;
  (5)TCP傳輸速度相對UDP較慢;
  (6)TCP有流量控制和擁塞控制,UDP沒有;
  (７)TCP是重量級協(xié)議,UDP是輕量級協(xié)議;
  (８)TCP首部較長２０字節(jié),UDP首部較短８字節(jié);
• 基于TCP和UDP的常用協(xié)議
  HTTP、HTTPS、FTP、TELNET、SMTP(簡單郵件傳輸協(xié)議)協(xié)議基于可靠的TCP協(xié)議。TFTP、DNS、DHCP、TFTP、SNMP(簡單網(wǎng)絡管理協(xié)議)、RIP基于不可靠的UDP協(xié)議
  TCP 和 UDP 的常用場景，這個問的好挺多的，例如我當時面試時，就被問過：QQ 登錄的過程中，用到了 TCP 和 UDP，QQ 通話呢？

4、HTTP1.0，1.1，2.0 的版本區(qū)別

• HTTP/1.0
  1996年5月，HTTP/1.0 版本發(fā)布，為了提高系統(tǒng)的效率，HTTP/1.0規(guī)定瀏覽器與服務器只保持短暫的連接，瀏覽器的每次請求都需要與服務器建立一個TCP連接，服務器完成請求處理后立即斷開TCP連接，服務器不跟蹤每個客戶也不記錄過去的請求。
  這種方式就好像我們打電話的時候，只能說一件事兒一樣，說完之后就要掛斷，想要說另外一件事兒的時候就要重新?lián)艽螂娫挕?br> HTTP/1.0中瀏覽器與服務器只保持短暫的連接，連接無法復用。也就是說每個TCP連接只能發(fā)送一個請求。發(fā)送數(shù)據(jù)完畢，連接就關閉，如果還要請求其他資源，就必須再新建一個連接。
  我們知道TCP連接的建立需要三次握手，是很耗費時間的一個過程。所以，HTTP/1.0版本的性能比較差。
  HTTP1.0 其實也可以強制開啟長鏈接，例如接受Connection: keep-alive 這個字段，但是，這不是標準字段，不同實現(xiàn)的行為可能不一致，因此不是根本的解決辦法。
• HTTP/1.1
  為了解決HTTP/1.0存在的缺陷，HTTP/1.1于1999年誕生。相比較于HTTP/1.0來說，最主要的改進就是引入了持久連接。所謂的持久連接即TCP連接默認不關閉，可以被多個請求復用。
  由于之前打一次電話只能說一件事兒，效率很低。后來人們提出一種想法，就是電話打完之后，先不直接掛斷，而是持續(xù)一小段時間，這一小段時間內(nèi)，如果還有事情溝通可以再次進行溝通。
  客戶端和服務器發(fā)現(xiàn)對方一段時間沒有活動，就可以主動關閉連接?；蛘呖蛻舳嗽谧詈笠粋€請求時，主動告訴服務端要關閉連接。
  HTTP/1.1版還引入了管道機制（pipelining），即在同一個TCP連接里面，客戶端可以同時發(fā)送多個請求。這樣就進一步改進了HTTP協(xié)議的效率。

有了持久連接和管道，大大的提升了HTTP的效率。但是服務端還是順序執(zhí)行的，效率還有提升的空間。

• HTTP/2
  HTTP/2 是 HTTP 協(xié)議自 1999 年 HTTP 1.1 發(fā)布后的首個更新，主要基于 SPDY 協(xié)議。
  HTTP/2 為了解決HTTP/1.1中仍然存在的效率問題，HTTP/2 采用了多路復用。即在一個連接里，客戶端和瀏覽器都可以同時發(fā)送多個請求或回應，而且不用按照順序一一對應。能這樣做有一個前提，就是HTTP/2進行了二進制分幀，即 HTTP/2 會將所有傳輸?shù)男畔⒎指顬楦〉南⒑蛶╢rame）,并對它們采用二進制格式的編碼。
  也就是說，老板可以同時下達多個命令，員工也可以收到了A請求和B請求，于是先回應A請求，結(jié)果發(fā)現(xiàn)處理過程非常耗時，于是就發(fā)送A請求已經(jīng)處理好的部分， 接著回應B請求，完成后，再發(fā)送A請求剩下的部分。A請求的兩部分響應在組合到一起發(fā)給老板。

而這個負責拆分、組裝請求和二進制幀的一層就叫做二進制分幀層。
除此之外，還有一些其他的優(yōu)化，比如做Header壓縮、服務端推送等。
Header壓縮就是壓縮老板和員工之間的對話。
服務端推送就是員工事先把一些老板可能詢問的事情提現(xiàn)發(fā)送到老板的手機（緩存）上。這樣老板想要知道的時候就可以直接讀取短信（緩存）了。
目前，主流的HTTP協(xié)議還是HTTP/1.1 和 HTTP/2。并且各大網(wǎng)站的HTTP/2的使用率也在逐年增加。

5、POST和GET有哪些區(qū)別？各自應用場景？

• 使用場景
  GET 用于獲取資源，而 POST 用于傳輸實體主體。
• 參數(shù)
  GET 和 POST 的請求都能使用額外的參數(shù)，但是 GET 的參數(shù)是以查詢字符串出現(xiàn)在 URL 中，而 POST 的參數(shù)存儲在實體主體中。不能因為 POST 參數(shù)存儲在實體主體中就認為它的安全性更高，因為照樣可以通過一些抓包工具（Fiddler）查看。
  因為 URL 只支持 ASCII 碼，因此 GET 的參數(shù)中如果存在中文等字符就需要先進行編碼。例如 中文 會轉(zhuǎn)換為 %E4%B8%AD%E6%96%87，而空格會轉(zhuǎn)換為 %20。POST 參數(shù)支持標準字符集。

GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1Copy to clipboardErrorCopied
POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2Copy to clipboardErrorCopied

• 安全性
  安全的 HTTP 方法不會改變服務器狀態(tài)，也就是說它只是可讀的。
  GET 方法是安全的，而 POST 卻不是，因為 POST 的目的是傳送實體主體內(nèi)容，這個內(nèi)容可能是用戶上傳的表單數(shù)據(jù)，上傳成功之后，服務器可能把這個數(shù)據(jù)存儲到數(shù)據(jù)庫中，因此狀態(tài)也就發(fā)生了改變。
  安全的方法除了 GET 之外還有：HEAD、OPTIONS。
  不安全的方法除了 POST 之外還有 PUT、DELETE。
• 冪等性
  冪等的 HTTP 方法，同樣的請求被執(zhí)行一次與連續(xù)執(zhí)行多次的效果是一樣的，服務器的狀態(tài)也是一樣的。換句話說就是，冪等方法不應該具有副作用（統(tǒng)計用途除外）。
  所有的安全方法也都是冪等的。
  在正確實現(xiàn)的條件下，GET，HEAD，PUT 和 DELETE 等方法都是冪等的，而 POST 方法不是。
  GET /pageX HTTP/1.1 是冪等的，連續(xù)調(diào)用多次，客戶端接收到的結(jié)果都是一樣的：

GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1Copy to clipboardErrorCopied

POST /add_row HTTP/1.1 不是冪等的，如果調(diào)用多次，就會增加多行記錄：

POST /add_row HTTP/1.1   -> Adds a 1nd row
POST /add_row HTTP/1.1   -> Adds a 2nd row
POST /add_row HTTP/1.1   -> Adds a 3rd rowCopy to clipboardErrorCopied

DELETE /idX/delete HTTP/1.1 是冪等的，即使不同的請求接收到的狀態(tài)碼不一樣：

DELETE /idX/delete HTTP/1.1   -> Returns 200 if idX exists
DELETE /idX/delete HTTP/1.1   -> Returns 404 as it just got deleted
DELETE /idX/delete HTTP/1.1   -> Returns 404Copy to clipboardErrorCopied

• 緩存
  如果要對響應進行緩存，需要滿足以下條件：
  請求報文的 HTTP 方法本身是可緩存的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可緩存，POST 在多數(shù)情況下不可緩存的。
  響應報文的狀態(tài)碼是可緩存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
  響應報文的 Cache-Control 首部字段沒有指定不進行緩存。
• XMLHttpRequest
  為了闡述 POST 和 GET 的另一個區(qū)別，需要先了解 XMLHttpRequest：
  XMLHttpRequest 是一個 API，它為客戶端提供了在客戶端和服務器之間傳輸數(shù)據(jù)的功能。它提供了一個通過 URL 來獲取數(shù)據(jù)的簡單方式，并且不會使整個頁面刷新。這使得網(wǎng)頁只更新一部分頁面而不會打擾到用戶。XMLHttpRequest 在 AJAX 中被大量使用。
  在使用 XMLHttpRequest 的 POST 方法時，瀏覽器會先發(fā)送 Header 再發(fā)送 Data。但并不是所有瀏覽器會這么做，例如火狐就不會。
  而 GET 方法 Header 和 Data 會一起發(fā)送。

6、HTTP 哪些常用的狀態(tài)碼及使用場景？

• 狀態(tài)碼分類
  1xx：表示目前是協(xié)議的中間狀態(tài)，還需要后續(xù)請求
  2xx：表示請求成功
  3xx：表示重定向狀態(tài)，需要重新請求
  4xx：表示請求報文錯誤
  5xx：服務器端錯誤
• 常用狀態(tài)碼
  101 切換請求協(xié)議，從 HTTP 切換到 WebSocket
  200 請求成功，有響應體
  301 永久重定向：會緩存
  302 臨時重定向：不會緩存
  304 協(xié)商緩存命中
  403 服務器禁止訪問
  404 資源未找到
  400 請求錯誤
  500 服務器端錯誤
  503 服務器繁忙

7、HTTP狀態(tài)碼301和302的區(qū)別，都有哪些用途？

• 301重定向的概念
  301重定向（301 Move Permanently），指頁面永久性轉(zhuǎn)移，表示為資源或頁面永久性地轉(zhuǎn)移到了另一個位置。301是HTTP協(xié)議中的一種狀態(tài)碼，當用戶或搜索引擎向服務器發(fā)出瀏覽請求時，服務器返回的HTTP數(shù)據(jù)流中頭信息（header）中包含狀態(tài)碼 301 ，表示該資源已經(jīng)永久改變了位置。
  301重定向是一種非常重要的”自動轉(zhuǎn)向“技術(shù)，網(wǎng)址重定向最為可行的一種方法。
• 哪些情況需要做301重定向？
  網(wǎng)頁開發(fā)過程中，時常會遇到網(wǎng)站目錄結(jié)構(gòu)的調(diào)整，將頁面轉(zhuǎn)移到一個新地址；網(wǎng)頁擴展名的改變，這些變化都會導致網(wǎng)頁地址發(fā)生改變，此時用戶收藏夾和搜索引擎數(shù)據(jù)庫中的舊地址是一個錯誤的地址，訪問之后會出現(xiàn)404頁面，直接導致網(wǎng)站流量的損失?；蛘呤俏覀冃枰鄠€域名跳轉(zhuǎn)至同一個域名，例如本站主站點域名為 www.conimi.com ，而還有一個域名 www.nico.cc，由于對該域名設置了301重定向，當輸入www.nico.cc 時，自動跳轉(zhuǎn)至 www.conimi.com 。
• 301重定向有什么優(yōu)點？
  有利于網(wǎng)站首選域的確定，對于同一資源頁面多條路徑的301重定向有助于URL權(quán)重的集中。例如 www.conimi.com和 conimi.com 是兩個不同的域名，但是指向的內(nèi)容完全相同，搜索引擎會對兩個域名收錄情況不同，這樣導致網(wǎng)站權(quán)重和排名被分散；對conimi.com 做301重定向跳轉(zhuǎn)至www.conimi.com 后，權(quán)重和排名集中到www.conimi.com，從而提升自然排名。
• 302重定向又是什么鬼？
  302重定向（302 Move Temporarily），指頁面暫時性轉(zhuǎn)移，表示資源或頁面暫時轉(zhuǎn)移到另一個位置，常被用作網(wǎng)址劫持，容易導致網(wǎng)站降權(quán)，嚴重時網(wǎng)站會被封掉，不推薦使用。
• 301與302的區(qū)別
  302重定向是頁面暫時性轉(zhuǎn)移，搜索引擎會抓取新的內(nèi)容而保存舊的網(wǎng)址并認為新的網(wǎng)址只是暫時的。

8、在交互過程中如果數(shù)據(jù)傳送完了，還不想斷開連接怎么辦，怎么維持？

在 HTTP 中響應體的 Connection 字段指定為 keep-alive
connetion:keep-alive;

9、HTTP 如何實現(xiàn)長連接？在什么時候會超時？

通過在頭部（請求和響應頭）設置 Connection: keep-alive，HTTP1.0協(xié)議支持，但是默認關閉，從HTTP1.1協(xié)議以后，連接默認都是長連接
1、HTTP 一般會有 httpd 守護進程，里面可以設置 keep-alive timeout，當 tcp 鏈接閑置超過這個時間就會關閉，也可以在 HTTP 的 header 里面設置超時時間
2、TCP 的 keep-alive 包含三個參數(shù)，支持在系統(tǒng)內(nèi)核的 net.ipv4 里面設置：當 TCP 鏈接之后，閑置了 tcp_keepalive_time，則會發(fā)生偵測包，如果沒有收到對方的 ACK，那么會每隔 tcp_keepalive_intvl 再發(fā)一次，直到發(fā)送了 tcp_keepalive_probes，就會丟棄該鏈接。
（1）tcp_keepalive_intvl = 15
（2）tcp_keepalive_probes = 5
（3）tcp_keepalive_time = 1800
實際上 HTTP 沒有長短鏈接，只有 TCP 有，TCP 長連接可以復用一個 TCP 鏈接來發(fā)起多次 HTTP 請求，這樣可以減少資源消耗，比如一次請求 HTML，可能還需要請求后續(xù)的 JS/CSS/圖片等

10、TCP 如何保證有效傳輸及擁塞控制原理

tcp 是面向連接的、可靠的、傳輸層通信協(xié)議

• 可靠體現(xiàn)在：有狀態(tài)、可控制
  有狀態(tài)是指 TCP 會確認發(fā)送了哪些報文，接收方受到了哪些報文，哪些沒有收到，保證數(shù)據(jù)包按序到達，不允許有差錯
  可控制的是指，如果出現(xiàn)丟包或者網(wǎng)絡狀況不佳，則會跳轉(zhuǎn)自己的行為，減少發(fā)送的速度或者重發(fā)
  所以上面能保證數(shù)據(jù)包的有效傳輸。
• 擁塞控制原理
  原因是有可能整個網(wǎng)絡環(huán)境特別差，容易丟包，那么發(fā)送端就應該注意了。
  主要用三種方法：慢啟動閾值 + 擁塞避免；快速重傳；快速回復
• 慢啟動閾值 + 擁塞避免：
  對于擁塞控制來說，TCP 主要維護兩個核心狀態(tài)：擁塞窗口（cwnd）、慢啟動閾值（ssthresh）
  在發(fā)送端使用擁塞窗口來控制發(fā)送窗口的大?。蝗缓蟛捎靡环N比較保守的慢啟動算法來慢慢適應這個網(wǎng)絡，在開始傳輸?shù)囊欢螘r間，發(fā)送端和接收端會首先通過三次握手建立連接，確定各自接收窗口大小，然后初始化雙方的擁塞窗口，接著每經(jīng)過一輪 RTT（收發(fā)時延），擁塞窗口大小翻倍，直到達到慢啟動閾值。
  然后開始進行擁塞避免，擁塞避免具體的做法就是之前每一輪 RTT，擁塞窗口翻倍，現(xiàn)在每一輪就加一個。
• 快速重傳：
  在 TCP 傳輸過程中，如果發(fā)生了丟包，接收端就會發(fā)送之前重復 ACK，比如 第 5 個包丟了，6、7 達到，然后接收端會為 5，6，7 都發(fā)送第四個包的 ACK，這個時候發(fā)送端受到了 3 個重復的 ACK，意識到丟包了，就會馬上進行重傳，而不用等到 RTO （超時重傳的時間）
  選擇性重傳：報文首部可選性中加入 SACK 屬性，通過 left edge 和 right edge 標志那些包到了，然后重傳沒到的包
• 快速回復：
  如果發(fā)送端收到了 3 個重復的 ACK，發(fā)現(xiàn)了丟包，覺得現(xiàn)在的網(wǎng)絡狀況已經(jīng)進入擁塞狀態(tài)了，那么就會進入快速恢復階段：
  會將擁塞閾值降低為 擁塞窗口的一半
  然后擁塞窗口大小變?yōu)閾砣撝?br> 接著 擁塞窗口再進行線性增加，以適應網(wǎng)絡狀況

11、IP地址有哪些分類？

A類地址(1~126)：網(wǎng)絡號占前8位，以0開頭，主機號占后24位。
B類地址(128~191)：網(wǎng)絡號占前16位，以10開頭，主機號占后16位。
C類地址(192~223)：網(wǎng)絡號占前24位，以110開頭，主機號占后8位。
D類地址(224~239)：以1110開頭，保留位多播地址。
E類地址(240~255)：以1111開頭，保留位今后使用

12、GET請求中URL編碼的意義

我們知道，在GET請求中會對URL中非西文字符進行編碼，這樣做的目的就是為了避免歧義。看下面的例子，
針對“name1=value1&name2=value2”的例子，我們來談一下數(shù)據(jù)從客戶端到服務端的解析過程。首先，上述字符串在計算機中用ASCII碼表示為：

   6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532
   6E616D6531：name1 
   3D：= 
   76616C756531：value1 
   26：&
   6E616D6532：name2 
   3D：= 
   76616C756532：value2

服務端在接收到該數(shù)據(jù)后就可以遍歷該字節(jié)流，一個字節(jié)一個字節(jié)的吃，當吃到3D這字節(jié)后，服務端就知道前面吃得字節(jié)表示一個key，再往后吃，如果遇到26，說明從剛才吃的3D到26子節(jié)之間的是上一個key的value，以此類推就可以解析出客戶端傳過來的參數(shù)。
現(xiàn)在考慮這樣一個問題，如果我們的參數(shù)值中就包含 = 或 & 這種特殊字符的時候該怎么辦？比如，“name1=value1”，其中value1的值是“va&lu=e1”字符串，那么實際在傳輸過程中就會變成這樣“name1=va&lu=e1”。這樣，我們的本意是只有一個鍵值對，但是服務端卻會解析成兩個鍵值對，這樣就產(chǎn)生了歧義。
那么，如何解決上述問題帶來的歧義呢？解決的辦法就是對參數(shù)進行URL編碼：例如，我們對上述會產(chǎn)生歧義的字符進行URL編碼后結(jié)果：“name1=va%26lu%3D”，這樣服務端會把緊跟在“%”后的字節(jié)當成普通的字節(jié)，就是不會把它當成各個參數(shù)或鍵值對的分隔符

13、什么是SQL 注入？舉個例子？

SQL注入就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執(zhí)行惡意的SQL命令。

• SQL注入攻擊的總體思路
  (1). 尋找到SQL注入的位置
  (2). 判斷服務器類型和后臺數(shù)據(jù)庫類型
  (3). 針對不通的服務器和數(shù)據(jù)庫特點進行SQL注入攻擊
• SQL注入攻擊實例
  比如，在一個登錄界面，要求輸入用戶名和密碼，可以這樣輸入實現(xiàn)免帳號登錄：
  用戶名： ‘or 1 = 1 --
  密 碼：
  用戶一旦點擊登錄，如若沒有做特殊處理，那么這個非法用戶就很得意的登陸進去了。這是為什么呢?
  下面我們分析一下：從理論上說，后臺認證程序中會有如下的SQL語句：

String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”;

因此，當輸入了上面的用戶名和密碼，上面的SQL語句變成：

SELECT * FROM user_table WHERE username=’’or 1 = 1 –- and password=’’

分析上述SQL語句我們知道，username=‘ or 1=1 這個語句一定會成功；然后后面加兩個 -，這意味著注釋，它將后面的語句注釋，讓他們不起作用。這樣，上述語句永遠都能正確執(zhí)行，用戶輕易騙過系統(tǒng)，獲取合法身份。

• 應對方法
  (1). 參數(shù)綁定
  使用預編譯手段，綁定參數(shù)是最好的防SQL注入的方法。目前許多的ORM框架及JDBC等都實現(xiàn)了SQL預編譯和參數(shù)綁定功能，攻擊者的惡意SQL會被當做SQL的參數(shù)而不是SQL命令被執(zhí)行。在mybatis的mapper文件中，對于傳遞的參數(shù)我們一般是使用 # 和時，變量就是直接追加在sql中，一般會有sql注入問題。
  (2). 使用正則表達式過濾傳入的參數(shù)

14、談一談 XSS 攻擊，舉個例子？

XSS是一種經(jīng)常出現(xiàn)在web應用中的計算機安全漏洞，與SQL注入一起成為web中最主流的攻擊方式。
XSS是指惡意攻擊者利用網(wǎng)站沒有對用戶提交數(shù)據(jù)進行轉(zhuǎn)義處理或者過濾不足的缺點，進而添加一些腳本代碼嵌入到web頁面中去，使別的用戶訪問都會執(zhí)行相應的嵌入代碼，從而盜取用戶資料、利用用戶身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式。

• 1). XSS攻擊的危害
  盜取各類用戶帳號，如機器登錄帳號、用戶網(wǎng)銀帳號、各類管理員帳號
  控制企業(yè)數(shù)據(jù)，包括讀取、篡改、添加、刪除企業(yè)敏感數(shù)據(jù)的能力
  盜竊企業(yè)重要的具有商業(yè)價值的資料
  非法轉(zhuǎn)賬
  強制發(fā)送電子郵件
  網(wǎng)站掛馬
  控制受害者機器向其它網(wǎng)站發(fā)起攻擊
• 2). 原因解析
  主要原因：過于信任客戶端提交的數(shù)據(jù)！
  解決辦法：不信任任何客戶端提交的數(shù)據(jù)，只要是客戶端提交的數(shù)據(jù)就應該先進行相應的過濾處理然后方可進行下一步的操作。
  進一步分析細節(jié)：客戶端提交的數(shù)據(jù)本來就是應用所需要的，但是惡意攻擊者利用網(wǎng)站對客戶端提交數(shù)據(jù)的信任，在數(shù)據(jù)中插入一些符號以及javascript代碼，那么這些數(shù)據(jù)將會成為應用代碼中的一部分了，那么攻擊者就可以肆無忌憚地展開攻擊啦，因此我們絕不可以信任任何客戶端提交的數(shù)據(jù)?。?！
• 3). XSS 攻擊分類
  (1). 反射性XSS攻擊 (非持久性XSS攻擊)
  漏洞產(chǎn)生的原因是攻擊者注入的數(shù)據(jù)反映在響應中。一個典型的非持久性XSS攻擊包含一個帶XSS攻擊向量的鏈接(即每次攻擊需要用戶的點擊)，例如，正常發(fā)送消息：
  http://www.test.com/message.php?send=Hello,World！
  接收者將會接收信息并顯示Hello,World；但是，非正常發(fā)送消息：
  http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>！
  接收者接收消息顯示的時候?qū)棾鼍娲翱冢?br> (2). 持久性XSS攻擊 (留言板場景)
  XSS攻擊向量(一般指XSS攻擊代碼)存儲在網(wǎng)站數(shù)據(jù)庫，當一個頁面被用戶打開的時候執(zhí)行。也就是說，每當用戶使用瀏覽器打開指定頁面時，腳本便執(zhí)行。
  與非持久性XSS攻擊相比，持久性XSS攻擊危害性更大。從名字就可以了解到，持久性XSS攻擊就是將攻擊代碼存入數(shù)據(jù)庫中，然后客戶端打開時就執(zhí)行這些攻擊代碼。
  例如，留言板表單中的表單域：
  <input type="text" name="content" value="這里是用戶填寫的數(shù)據(jù)">
  正常操作流程是：用戶是提交相應留言信息 —— 將數(shù)據(jù)存儲到數(shù)據(jù)庫 —— 其他用戶訪問留言板，應用去數(shù)據(jù)并顯示；而非正常操作流程是攻擊者在value填寫:
  <script>alert(‘foolish!’)；</script>
  并將數(shù)據(jù)提交、存儲到數(shù)據(jù)庫中；當其他用戶取出數(shù)據(jù)顯示的時候，將會執(zhí)行這些攻擊性代碼。
• 4). 修復漏洞方針
  漏洞產(chǎn)生的根本原因是 太相信用戶提交的數(shù)據(jù)，對用戶所提交的數(shù)據(jù)過濾不足所導致的，因此解決方案也應該從這個方面入手，具體方案包括：
  將重要的cookie標記為http only, 這樣的話Javascript 中的document.cookie語句就不能獲取到cookie了（如果在cookie中設置了HttpOnly屬性，那么通過js腳本將無法讀取到cookie信息，這樣能有效的防止XSS攻擊）；
  表單數(shù)據(jù)規(guī)定值的類型，例如：年齡應為只能為int、name只能為字母數(shù)字組合。。。。
  對數(shù)據(jù)進行Html Encode 處理
  過濾或移除特殊的Html標簽，例如:

15、講一下網(wǎng)絡五層模型，每一層的職責？

• 前言
  天各一方的兩臺計算機是如何通信的呢？在成千上萬的計算機中，為什么一臺計算機能夠準確著尋找到另外一臺計算機，并且把數(shù)據(jù)發(fā)送給它呢？
  可能很多人都聽說過網(wǎng)絡通信的 5 層模型，但是可能并不是很清楚為什么需要五層模型，五層模型負責的任務也有可能經(jīng)常混淆。下面是網(wǎng)絡通信的五層模型
  說實話，五層模型的具體內(nèi)容還是極其復雜的，不過今天這篇文章，我將用最簡潔的模式，通過網(wǎng)絡通信的五層模型來講解一臺計算機是如何找到另外一臺計算機并且把數(shù)據(jù)發(fā)送給另一臺計算機的，就算你沒學過計算機網(wǎng)絡，也能夠聽的懂。
• 1. 物理層
     一臺計算機與另一臺計算機要進行通信，第一件要做的事是什么？當然是要把這臺計算機與另外的其他計算機連起來啊，這樣，我們才能把數(shù)據(jù)傳輸過去。例如可以通過光纖啊，電纜啊，雙絞線啊等介質(zhì)把他們連接起來，然后才能進行通信。
     也就是說，物理層負責把兩臺計算機連起來，然后在計算機之間通過高低電頻來傳送0,1這樣的電信號。
• 2. 數(shù)據(jù)鏈路層
     前面說了，物理層它只是單純著負責把計算機連接起來，并且在計算機之間傳輸0，1這樣的電信號。如果這些0，1組合的傳送毫無規(guī)則的話，計算機是解讀不了的。一大堆0，1誰知道是什么鬼啊。
     因此，我們需要制定一套規(guī)則來進行0，1的傳送。例如多少個電信號為一組啊，每一組信號應該如何標識才能讓計算機讀懂啊等等。
     于是，有了以太網(wǎng)協(xié)議。
     (1). 以太網(wǎng)協(xié)議
     以太網(wǎng)協(xié)議規(guī)定，一組電信號構(gòu)成一個數(shù)據(jù)包，我們把這個數(shù)據(jù)包稱之為幀。每一個楨由標頭(Head)和數(shù)據(jù)(Data)兩部分組成。
     幀的大小一般為 64 – 1518 個字節(jié)。假如需要傳送的數(shù)據(jù)很大的話，就分成多個楨來進行傳送。
     對于表頭和數(shù)據(jù)這兩個部分，他們存放的都是一些什么數(shù)據(jù)呢？我猜你瞇著眼睛都能想到他們應該放什么數(shù)據(jù)。 毫無疑問，我們至少得知道這個楨是誰發(fā)送，發(fā)送給誰的等這些信息吧？所以標頭部分主要是一些說明數(shù)據(jù)，例如發(fā)送者，接收者等信息。而數(shù)據(jù)部分則是這個數(shù)據(jù)包具體的，想給接守者的內(nèi)容。
     大家想一個問題，一個楨的長度是 64~1518 個字節(jié)，也就是說楨的長度不是固定的，那你覺得標頭部分的字節(jié)長度是固定的嗎？它當然是固定的啊，假如不是固定的，每個楨都是單獨發(fā)的，那計算機怎么知道標頭是幾個字節(jié)，數(shù)據(jù)是幾個字節(jié)呢。所以標頭部分的字節(jié)是固定的，并且固定為18個字節(jié)。
     把一臺計算的的數(shù)據(jù)通過物理層和鏈路層發(fā)送給另一臺計算機，究竟是誰發(fā)給誰的，計算機與計算機之間如何區(qū)分，，你總得給他們一個唯一的標識吧？
     于是，MAC 地址出現(xiàn)了。
     (2). MAC 地址
     連入網(wǎng)絡的每一個計算機都會有網(wǎng)卡接口，每一個網(wǎng)卡都會有一個唯一的地址，這個地址就叫做 MAC 地址。計算機之間的數(shù)據(jù)傳送，就是通過 MAC 地址來唯一尋找、傳送的。
     MAC地址 由 48 個字節(jié)所構(gòu)成，在網(wǎng)卡生產(chǎn)時就被唯一標識了。
     (3). 廣播與ARP協(xié)議
     1). 廣播
     如圖，假如計算機 A 知道了計算機 B 的 MAC 地址，然后計算機 A 想要給計算機 B 傳送數(shù)據(jù)，雖然計算機 A 知道了計算機 B 的 MAC 地址，可是它要怎么給它傳送數(shù)據(jù)呢？計算機 A 不僅連著計算機 B，而且計算機 A 也還連著其他的計算機。 雖然計算機 A 知道計算機 B 的 MAC 地址，可是計算機 A 卻不知道知道計算機 B 是分布在哪邊路線上，為了解決這個問題，于是，有了廣播的出現(xiàn)。
     在同一個子網(wǎng)中，計算機 A 要向計算機 B 發(fā)送一個數(shù)據(jù)包，這個數(shù)據(jù)包會包含接收者的 MAC 地址。當發(fā)送時，計算機 A 是通過廣播的方式發(fā)送的，這時同一個子網(wǎng)中的計算機 C, D 也會收到這個數(shù)據(jù)包的，然后收到這個數(shù)據(jù)包的計算機，會把數(shù)據(jù)包的 MAC 地址取出來，與自身的 MAC 地址對比，如果兩者相同，則接受這個數(shù)據(jù)包，否則就丟棄這個數(shù)據(jù)包。這種發(fā)送方式我們稱之為廣播,就像我們平時在廣場上通過廣播的形式呼叫某個人一樣，如果這個名字是你，你就理會一下，如果不是你，你就當作聽不見。
     2). ARP 協(xié)議。
     那么問題來了，計算機 A 是如何知道計算機 B 的 MAC 地址的呢？這個時候就得由 ARP 協(xié)議這個家伙來解決了，不過 ARP 協(xié)議會涉及到IP地址，我們下面才會扯到IP地址。因此我們先放著，就當作是有這么一個 ARP 協(xié)議，通過它我們可以知道子網(wǎng)中其他計算機的 MAC 地址。
• 3. 網(wǎng)絡層
     上面我們有說到子網(wǎng)這個關鍵詞，實際上我們所處的網(wǎng)絡，是由無數(shù)個子網(wǎng)絡構(gòu)成的。廣播的時候，也只有同一個子網(wǎng)里面的計算機能夠收到。
     假如沒有子網(wǎng)這種劃分的話，計算機 A 通過廣播的方式發(fā)一個數(shù)據(jù)包給計算機 B , 其他所有計算機也都能收到這個數(shù)據(jù)包，然后進行對比再舍棄。世界上有那么多它計算機，每一臺計算機都能收到其他所有計算機的數(shù)據(jù)包，那就不得了了。那還不得奔潰。 因此產(chǎn)生了子網(wǎng)這么一個東西。
     那么問題來了，我們?nèi)绾螀^(qū)分哪些 MAC 地址是屬于同一個子網(wǎng)的呢？假如是同一個子網(wǎng)，那我們就用廣播的形式把數(shù)據(jù)傳送給對方，如果不是同一個子網(wǎng)的，我們就會把數(shù)據(jù)發(fā)給網(wǎng)關，讓網(wǎng)關進行轉(zhuǎn)發(fā)。
     為了解決這個問題，于是，有了 IP 協(xié)議。
     (1). IP協(xié)議
     IP協(xié)議，它所定義的地址，我們稱之為IP地址。IP協(xié)議有兩種版本，一種是 IPv4,另一種是 IPv6。不過我們目前大多數(shù)用的還是 IPv4，我們現(xiàn)在也只討論 IPv4 這個版本的協(xié)議。
     這個 IP 地址由 32 位的二進制數(shù)組成，我們一般把它分成4段的十進制表示，地址范圍為0.0.0.0~255.255.255.255。
     每一臺想要聯(lián)網(wǎng)的計算機都會有一個IP地址。這個IP地址被分為兩部分，前面一部分代表網(wǎng)絡部分，后面一部分代表主機部分。并且網(wǎng)絡部分和主機部分所占用的二進制位數(shù)是不固定的。
     假如兩臺計算機的網(wǎng)絡部分是一模一樣的，我們就說這兩臺計算機是處于同一個子網(wǎng)中。例如 192.168.43.1 和 192.168.43.2, 假如這兩個 IP 地址的網(wǎng)絡部分為 24 位，主機部分為 8 位。那么他們的網(wǎng)絡部分都為 192.168.43，所以他們處于同一個子網(wǎng)中。
     可是問題來了，你怎么知道網(wǎng)絡部分是占幾位，主機部分又是占幾位呢？也就是說，單單從兩臺計算機的IP地址，我們是無法判斷他們的是否處于同一個子網(wǎng)中的。
     這就引申出了另一個關鍵詞——子網(wǎng)掩碼。子網(wǎng)掩碼和IP地址一樣也是 32 位二進制數(shù)，不過它的網(wǎng)絡部分規(guī)定全部為 1，主機部分規(guī)定全部為 0.也就是說，假如上面那兩個IP地址的網(wǎng)絡部分為 24 位，主機部分為 8 位的話，那他們的子網(wǎng)掩碼都為 11111111.11111111.11111111.00000000，即255.255.255.0。
     那有了子網(wǎng)掩碼，如何來判端IP地址是否處于同一個子網(wǎng)中呢。顯然，知道了子網(wǎng)掩碼，相當于我們知道了網(wǎng)絡部分是幾位，主機部分是幾位。我們只需要把 IP 地址與它的子網(wǎng)掩碼做與(and)運算，然后把各自的結(jié)果進行比較就行了，如果比較的結(jié)果相同，則代表是同一個子網(wǎng)，否則不是同一個子網(wǎng)。
     例如，192.168.43.1和192.168.43.2的子碼掩碼都為255.255.255.0，把IP與子碼掩碼相與，可以得到他們都為192.168.43.0，進而他們處于同一個子網(wǎng)中。
     (2). ARP協(xié)議
     有了上面IP協(xié)議的知識，我們回來講一下ARP協(xié)議。
     有了兩臺計算機的IP地址與子網(wǎng)掩碼，我們就可以判斷出它們是否處于同一個子網(wǎng)之中了。
     假如他們處于同一個子網(wǎng)之中，計算機A要給計算機B發(fā)送數(shù)據(jù)時。我們可以通過ARP協(xié)議來得到計算機B的MAC地址。
     ARP協(xié)議也是通過廣播的形式給同一個子網(wǎng)中的每臺電腦發(fā)送一個數(shù)據(jù)包(當然，這個數(shù)據(jù)包會包含接收方的IP地址)。對方收到這個數(shù)據(jù)包之后，會取出IP地址與自身的對比，如果相同，則把自己的MAC地址回復給對方，否則就丟棄這個數(shù)據(jù)包。這樣，計算機A就能知道計算機B的MAC地址了。
     可能有人會問，知道了MAC地址之后，發(fā)送數(shù)據(jù)是通過廣播的形式發(fā)送，詢問對方的MAC地址也是通過廣播的形式來發(fā)送，那其他計算機怎么知道你是要傳送數(shù)據(jù)還是要詢問MAC地址呢？其實在詢問MAC地址的數(shù)據(jù)包中，在對方的MAC地址這一欄中，填的是一個特殊的MAC地址，其他計算機看到這個特殊的MAC地址之后，就能知道廣播想干嘛了。
     假如兩臺計算機的IP不是處于同一個子網(wǎng)之中，這個時候，我們就會把數(shù)據(jù)包發(fā)送給網(wǎng)關，然后讓網(wǎng)關讓我們進行轉(zhuǎn)發(fā)傳送
     (3). DNS服務器
     這里再說一個問題，我們是如何知道對方計算機的IP地址的呢？這個問題可能有人會覺得很白癡，心想，當然是計算機的操作者來進行輸入了。這沒錯，當我們想要訪問某個網(wǎng)站的時候，我們可以輸入IP來進行訪問，但是我相信絕大多數(shù)人是輸入一個網(wǎng)址域名的，例如訪問百度是輸入 www.baidu.com 這個域名。其實當我們輸入這個域名時，會有一個叫做DNS服務器的家伙來幫我們解析這個域名，然后返回這個域名對應的IP給我們的。
     因此，網(wǎng)絡層的功能就是讓我們在茫茫人海中，能夠找到另一臺計算機在哪里，是否屬于同一個子網(wǎng)等。
• 4. 傳輸層
     通過物理層、數(shù)據(jù)鏈路層以及網(wǎng)絡層的互相幫助，我們已經(jīng)把數(shù)據(jù)成功從計算機A傳送到計算機B了，可是，計算機B里面有各種各樣的應用程序，計算機該如何知道這些數(shù)據(jù)是給誰的呢？
     這個時候，端口(Port)這個家伙就上場了，也就是說，我們在從計算機A傳數(shù)據(jù)給計算機B的時候，還得指定一個端口，以供特定的應用程序來接受處理。
     也就是說，傳輸層的功能就是建立端口到端口的通信。相比網(wǎng)絡層的功能是建立主機到主機的通信。
     也就是說，只有有了IP和端口，我們才能進行準確著通信。這個時候可能有人會說，我輸入IP地址的時候并沒有指定一個端口啊。其實呢，對于有些傳輸協(xié)議，已經(jīng)有設定了一些默認端口了。例如http的傳輸默認端口是80，這些端口信息也會包含在數(shù)據(jù)包里的。
     傳輸層最常見的兩大協(xié)議是 TCP 協(xié)議和 UDP 協(xié)議，其中 TCP 協(xié)議與 UDP 最大的不同就是 TCP 提供可靠的傳輸，而 UDP 提供的是不可靠傳輸。
• 5. 應用層
     終于說到應用層了，應用層這一層最接近我們用戶了。
     雖然我們收到了傳輸層傳來的數(shù)據(jù)，可是這些傳過來的數(shù)據(jù)五花八門，有html格式的，有mp4格式的，各種各樣。你確定你能看的懂？
     因此我們需要指定這些數(shù)據(jù)的格式規(guī)則，收到后才好解讀渲染。例如我們最常見的 Http 數(shù)據(jù)包中，就會指定該數(shù)據(jù)包是 什么格式的文件了。
• 總結(jié)
  五層模型至此講到這里。對于有些層講的比較簡潔，就隨便概況了一下。因為如果我說的詳細一點的話，篇幅肯定會特別特別長，我著已經(jīng)是盡最大的努力以最簡潔的方式來講的了。如果你想詳細去了解，可以去買計算機網(wǎng)絡相應的資料，強烈推薦《計算機網(wǎng)絡：自頂向下》這本書。希望我的講解能讓你對計算機之間數(shù)據(jù)的傳輸有個大概的了解。

16、簡單說下 HTTPS 和 HTTP 的區(qū)別

Http協(xié)議運行在TCP之上，明文傳輸，客戶端與服務器端都無法驗證對方的身份；Https是身披SSL(Secure Socket Layer)外殼的Http，運行于SSL上，SSL運行于TCP之上，是添加了加密和認證機制的HTTP。二者之間存在如下不同：

• 1、端口不同：Http與Https使用不同的連接方式，用的端口也不一樣，前者是80，后者是443；
• 2、資源消耗：和HTTP通信相比，Https通信會由于加減密處理消耗更多的CPU和內(nèi)存資源；
• 3、開銷：Https通信需要證書，而證書一般需要向認證機構(gòu)購買；
  Https的加密機制是一種共享密鑰加密和公開密鑰加密并用的混合加密機制。

17、對稱加密與非對稱加密的區(qū)別

對稱密鑰加密是指加密和解密使用同一個密鑰的方式，這種方式存在的最大問題就是密鑰發(fā)送問題，即如何安全地將密鑰發(fā)給對方。
非對稱加密是指使用一對非對稱密鑰，即公鑰和私鑰，公鑰可以隨意發(fā)布，但私鑰只有自己知道。發(fā)送密文的一方使用對方的公鑰進行加密處理，對方接收到加密信息后，使用自己的私鑰進行解密。
由于非對稱加密的方式不需要發(fā)送用來解密的私鑰，所以可以保證安全性；但是和對稱加密比起來，它非常的慢，所以我們還是要用對稱加密來傳送消息，但對稱加密所使用的密鑰我們可以通過非對稱加密的方式發(fā)送出去。

18、簡單說下每一層對應的網(wǎng)絡協(xié)議有哪些？

計算機五層網(wǎng)絡體系中涉及的協(xié)議非常多，下面就常用的做了列舉：

19、ARP 協(xié)議的工作原理？

網(wǎng)絡層的 ARP 協(xié)議完成了IP 地址與物理地址的映射。首先，每臺主機都會在自己的 ARP 緩沖區(qū)中建立一個 ARP 列表，以表示 IP 地址和 MAC 地址的對應關系。當源主機需要將一個數(shù)據(jù)包要發(fā)送到目的主機時，會首先檢查自己 ARP 列表中是否存在該 IP 地址對應的 MAC 地址：如果有，就直接將數(shù)據(jù)包發(fā)送到這個 MAC 地址；如果沒有，就向本地網(wǎng)段發(fā)起一個 ARP 請求的廣播包，查詢此目的主機對應的 MAC 地址。
此 ARP 請求數(shù)據(jù)包里包括源主機的 IP 地址、硬件地址、以及目的主機的 IP 地址。網(wǎng)絡中所有的主機收到這個 ARP 請求后，會檢查數(shù)據(jù)包中的目的 IP 是否和自己的 IP 地址一致。如果不相同就忽略此數(shù)據(jù)包；如果相同，該主機首先將發(fā)送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中，如果 ARP 表中已經(jīng)存在該 IP 的信息，則將其覆蓋，然后給源主機發(fā)送一個 ARP 響應數(shù)據(jù)包，告訴對方自己是它需要查找的 MAC 地址；源主機收到這個 ARP 響應數(shù)據(jù)包后，將得到的目的主機的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息開始數(shù)據(jù)的傳輸。如果源主機一直沒有收到 ARP 響應數(shù)據(jù)包，表示 ARP 查詢失敗

20、TCP的主要特點

• 1 TCP 是面向連接的。（就好像打電話一樣，通話前需要先撥號建立連接，通話結(jié)束后要掛機釋放連接）；
• 2 每一條 TCP 連接只能有兩個端點，每一條 TCP 連接只能是點對點的（一對一）；
• 3 TCP 提供可靠交付的服務。通過 TCP 連接傳送的數(shù)據(jù)，無差錯、不丟失、不重復、并且按序到達；
• 4 TCP 提供全雙工通信。TCP 允許通信雙方的應用進程在任何時候都能發(fā)送數(shù)據(jù)。TCP 連接的兩端都設有發(fā)送緩存和接收緩存，用來臨時存放雙方通信的數(shù)據(jù)；
• 5 面向字節(jié)流。TCP 中的“流”（Stream）指的是流入進程或從進程流出的字節(jié)序列?！懊嫦蜃止?jié)流”的含義是：雖然應用程序和 TCP 的交互是一次一個數(shù)據(jù)塊（大小不等），但 TCP 把應用程序交下來的數(shù)據(jù)僅僅看成是一連串的無結(jié)構(gòu)的字節(jié)流。

21、UDP 的主要特點是什么？

• 1 UDP 是無連接的；
• 2 UDP 使用盡最大努力交付，即不保證可靠交付，因此主機不需要維持復雜的鏈接狀態(tài)（這里面有許多參數(shù)）；
• 3 UDP 是面向報文的；
• 4 UDP 沒有擁塞控制，因此網(wǎng)絡出現(xiàn)擁塞不會使源主機的發(fā)送速率降低（對實時應用很有用，如 直播，實時視頻會議等）；
• 5 UDP 支持一對一、一對多、多對一和多對多的交互通信；
• 6 UDP 的首部開銷小，只有 8 個字節(jié)，比 TCP 的 20 個字節(jié)的首部要短。

22、TCP 和 UDP 分別對應的常見應用層協(xié)議有哪些？

• 1. TCP 對應的應用層協(xié)議
     FTP：定義了文件傳輸協(xié)議，使用 21 端口。常說某某計算機開了 FTP 服務便是啟動了文件傳輸服務。下載文件，上傳主頁，都要用到 FTP 服務。
     Telnet：它是一種用于遠程登陸的端口，用戶可以以自己的身份遠程連接到計算機上，通過這種端口可以提供一種基于 DOS 模式下的通信服務。如以前的 BBS 是-純字符界面的，支持 BBS 的服務器將 23 端口打開，對外提供服務。
     SMTP：定義了簡單郵件傳送協(xié)議，現(xiàn)在很多郵件服務器都用的是這個協(xié)議，用于發(fā)送郵件。如常見的免費郵件服務中用的就是這個郵件服務端口，所以在電子郵件設置-中?？吹接羞@么 SMTP 端口設置這個欄，服務器開放的是 25 號端口。
     POP3：它是和 SMTP 對應，POP3 用于接收郵件。通常情況下，POP3 協(xié)議所用的是 110 端口。也是說，只要你有相應的使用 POP3 協(xié)議的程序（例如 Fo-xmail 或 Outlook），就可以不以 Web 方式登陸進郵箱界面，直接用郵件程序就可以收到郵件（如是163 郵箱就沒有必要先進入網(wǎng)易網(wǎng)站，再進入自己的郵-箱來收信）。
     HTTP：從 Web 服務器傳輸超文本到本地瀏覽器的傳送協(xié)議。
• 2. UDP 對應的應用層協(xié)議
     DNS：用于域名解析服務，將域名地址轉(zhuǎn)換為 IP 地址。DNS 用的是 53 號端口。
     SNMP：簡單網(wǎng)絡管理協(xié)議，使用 161 號端口，是用來管理網(wǎng)絡設備的。由于網(wǎng)絡設備很多，無連接的服務就體現(xiàn)出其優(yōu)勢。
     TFTP(Trival File Transfer Protocal)：簡單文件傳輸協(xié)議，該協(xié)議在熟知端口 69 上使用 UDP 服務。

23、為什么 TIME-WAIT 狀態(tài)必須等待 2MSL 的時間呢？

• 1、為了保證 A 發(fā)送的最后一個 ACK 報文段能夠到達 B。這個 ACK 報文段有可能丟失，因而使處在 LAST-ACK 狀態(tài)的 B 收不到對已發(fā)送的 FIN + ACK 報文段的確認。B 會超時重傳這個 FIN+ACK 報文段，而 A 就能在 2MSL 時間內(nèi)（超時 + 1MSL 傳輸）收到這個重傳的 FIN+ACK 報文段。接著 A 重傳一次確認，重新啟動 2MSL 計時器。最后，A 和 B 都正常進入到 CLOSED 狀態(tài)。如果 A 在 TIME-WAIT 狀態(tài)不等待一段時間，而是在發(fā)送完 ACK 報文段后立即釋放連接，那么就無法收到 B 重傳的 FIN + ACK 報文段，因而也不會再發(fā)送一次確認報文段，這樣，B 就無法按照正常步驟進入 CLOSED 狀態(tài)。
• 2、 防止已失效的連接請求報文段出現(xiàn)在本連接中。A 在發(fā)送完最后一個 ACK 報文段后，再經(jīng)過時間 2MSL，就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡中消失。這樣就可以使下一個連接中不會出現(xiàn)這種舊的連接請求報文段。

24、?；钣嫊r器的作用？

除時間等待計時器外，TCP 還有一個?；钣嫊r器（keepalive timer）。設想這樣的場景：客戶已主動與服務器建立了 TCP 連接。但后來客戶端的主機突然發(fā)生故障。顯然，服務器以后就不能再收到客戶端發(fā)來的數(shù)據(jù)。因此，應當有措施使服務器不要再白白等待下去。這就需要使用?；钣嫊r器了。
服務器每收到一次客戶的數(shù)據(jù)，就重新設置?；钣嫊r器，時間的設置通常是兩個小時。若兩個小時都沒有收到客戶端的數(shù)據(jù)，服務端就發(fā)送一個探測報文段，以后則每隔 75 秒鐘發(fā)送一次。若連續(xù)發(fā)送 10個 探測報文段后仍然無客戶端的響應，服務端就認為客戶端出了故障，接著就關閉這個連接。

25、TCP 協(xié)議是如何保證可靠傳輸?shù)模?/h4>

• 數(shù)據(jù)包校驗：目的是檢測數(shù)據(jù)在傳輸過程中的任何變化，若校驗出包有錯，則丟棄報文段并且不給出響應，這時 TCP 發(fā)送數(shù)據(jù)端超時后會重發(fā)數(shù)據(jù)；
• 對失序數(shù)據(jù)包重排序：既然 TCP 報文段作為 IP 數(shù)據(jù)報來傳輸，而 IP 數(shù)據(jù)報的到達可能會失序，因此 TCP 報文段的到達也可能會失序。TCP 將對失序數(shù)據(jù)進行重新排序，然后才交給應用層；
• 丟棄重復數(shù)據(jù)：對于重復數(shù)據(jù)，能夠丟棄重復數(shù)據(jù)；
• 應答機制：當 TCP 收到發(fā)自 TCP 連接另一端的數(shù)據(jù)，它將發(fā)送一個確認。這個確認不是立即發(fā)送，通常將推遲幾分之一秒；
• 超時重發(fā)：當 TCP 發(fā)出一個段后，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發(fā)這個報文段；
• 流量控制：TCP 連接的每一方都有固定大小的緩沖空間。TCP 的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)，這可以防止較快主機致使較慢主機的緩沖區(qū)溢出，這就是流量控制。TCP 使用的流量控制協(xié)議是可變大小的滑動窗口協(xié)議。

26、談談你對停止等待協(xié)議的理解？

停止等待協(xié)議是為了實現(xiàn)可靠傳輸，它的基本原理就是每發(fā)完一個分組就停止發(fā)送，等待對方確認。在收到確認后再發(fā)下一個分組；在停止等待協(xié)議中，若接收方收到重復分組，就丟棄該分組，但同時還要發(fā)送確認。主要包括以下幾種情況：無差錯情況、出現(xiàn)差錯情況（超時重傳）、確認丟失和確認遲到、確認丟失和確認遲到。

27、談談你對 ARQ 協(xié)議的理解？

• 自動重傳請求 ARQ 協(xié)議
  停止等待協(xié)議中超時重傳是指只要超過一段時間仍然沒有收到確認，就重傳前面發(fā)送過的分組（認為剛才發(fā)送過的分組丟失了）。因此每發(fā)送完一個分組需要設置一個超時計時器，其重傳時間應比數(shù)據(jù)在分組傳輸?shù)钠骄禃r間更長一些。這種自動重傳方式常稱為自動重傳請求 ARQ。
• 連續(xù) ARQ 協(xié)議
  連續(xù) ARQ 協(xié)議可提高信道利用率。發(fā)送方維持一個發(fā)送窗口，凡位于發(fā)送窗口內(nèi)的分組可以連續(xù)發(fā)送出去，而不需要等待對方確認。接收方一般采用累計確認，對按序到達的最后一個分組發(fā)送確認，表明到這個分組為止的所有分組都已經(jīng)正確收到了。

28、談談你對滑動窗口的了解？

TCP 利用滑動窗口實現(xiàn)流量控制的機制?；瑒哟翱冢⊿liding window）是一種流量控制技術(shù)。早期的網(wǎng)絡通信中，通信雙方不會考慮網(wǎng)絡的擁擠情況直接發(fā)送數(shù)據(jù)。由于大家不知道網(wǎng)絡擁塞狀況，同時發(fā)送數(shù)據(jù)，導致中間節(jié)點阻塞掉包，誰也發(fā)不了數(shù)據(jù)，所以就有了滑動窗口機制來解決此問題。
TCP 中采用滑動窗口來進行傳輸控制，滑動窗口的大小意味著接收方還有多大的緩沖區(qū)可以用于接收數(shù)據(jù)。發(fā)送方可以通過滑動窗口的大小來確定應該發(fā)送多少字節(jié)的數(shù)據(jù)。當滑動窗口為 0 時，發(fā)送方一般不能再發(fā)送數(shù)據(jù)報，但有兩種情況除外，一種情況是可以發(fā)送緊急數(shù)據(jù)，例如，允許用戶終止在遠端機上的運行進程。另一種情況是發(fā)送方可以發(fā)送一個 1 字節(jié)的數(shù)據(jù)報來通知接收方重新聲明它希望接收的下一字節(jié)及發(fā)送方的滑動窗口大小。

29、談下你對流量控制的理解？

TCP 利用滑動窗口實現(xiàn)流量控制。流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來得及接收。接收方發(fā)送的確認報文中的窗口字段可以用來控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率。將窗口字段設置為 0，則發(fā)送方不能發(fā)送數(shù)據(jù)。

30、談下你對 TCP 擁塞控制的理解？使用了哪些算法？

擁塞控制和流量控制不同，前者是一個全局性的過程，而后者指點對點通信量的控制。在某段時間，若對網(wǎng)絡中某一資源的需求超過了該資源所能提供的可用部分，網(wǎng)絡的性能就要變壞。這種情況就叫擁塞。
擁塞控制就是為了防止過多的數(shù)據(jù)注入到網(wǎng)絡中，這樣就可以使網(wǎng)絡中的路由器或鏈路不至于過載。擁塞控制所要做的都有一個前提，就是網(wǎng)絡能夠承受現(xiàn)有的網(wǎng)絡負荷。擁塞控制是一個全局性的過程，涉及到所有的主機，所有的路由器，以及與降低網(wǎng)絡傳輸性能有關的所有因素。相反，流量控制往往是點對點通信量的控制，是個端到端的問題。流量控制所要做到的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便使接收端來得及接收。
為了進行擁塞控制，TCP 發(fā)送方要維持一個擁塞窗口(cwnd) 的狀態(tài)變量。擁塞控制窗口的大小取決于網(wǎng)絡的擁塞程度，并且動態(tài)變化。發(fā)送方讓自己的發(fā)送窗口取為擁塞窗口和接收方的接受窗口中較小的一個。
TCP 的擁塞控制采用了四種算法，即：慢開始、擁塞避免、快重傳和快恢復。在網(wǎng)絡層也可以使路由器采用適當?shù)姆纸M丟棄策略（如：主動隊列管理 AQM），以減少網(wǎng)絡擁塞的發(fā)生。

• 慢開始：
  慢開始算法的思路是當主機開始發(fā)送數(shù)據(jù)時，如果立即把大量數(shù)據(jù)字節(jié)注入到網(wǎng)絡，那么可能會引起網(wǎng)絡阻塞，因為現(xiàn)在還不知道網(wǎng)絡的符合情況。經(jīng)驗表明，較好的方法是先探測一下，即由小到大逐漸增大發(fā)送窗口，也就是由小到大逐漸增大擁塞窗口數(shù)值。cwnd 初始值為 1，每經(jīng)過一個傳播輪次，cwnd 加倍。
• 擁塞避免：
  擁塞避免算法的思路是讓擁塞窗口cwnd緩慢增大，即每經(jīng)過一個往返時間RTT就把發(fā)送方的cwnd加1。
• 快重傳與快恢復：
  在 TCP/IP 中，快速重傳和快恢復（fast retransmit and recovery，F(xiàn)RR）是一種擁塞控制算法，它能快速恢復丟失的數(shù)據(jù)包。
  沒有 FRR，如果數(shù)據(jù)包丟失了，TCP 將會使用定時器來要求傳輸暫停。在暫停的這段時間內(nèi)，沒有新的或復制的數(shù)據(jù)包被發(fā)送。有了 FRR，如果接收機接收到一個不按順序的數(shù)據(jù)段，它會立即給發(fā)送機發(fā)送一個重復確認。如果發(fā)送機接收到三個重復確認，它會假定確認件指出的數(shù)據(jù)段丟失了，并立即重傳這些丟失的數(shù)據(jù)段。
  有了 FRR，就不會因為重傳時要求的暫停被耽誤。當有單獨的數(shù)據(jù)包丟失時，快速重傳和快恢復（FRR）能最有效地工作。當有多個數(shù)據(jù)信息包在某一段很短的時間內(nèi)丟失時，它則不能很有效地工作。

31、什么是粘包？

在進行 Java NIO 學習時，可能會發(fā)現(xiàn)：如果客戶端連續(xù)不斷的向服務端發(fā)送數(shù)據(jù)包時，服務端接收的數(shù)據(jù)會出現(xiàn)兩個數(shù)據(jù)包粘在一起的情況。
TCP 是基于字節(jié)流的，雖然應用層和 TCP 傳輸層之間的數(shù)據(jù)交互是大小不等的數(shù)據(jù)塊，但是 TCP 把這些數(shù)據(jù)塊僅僅看成一連串無結(jié)構(gòu)的字節(jié)流，沒有邊界；
從 TCP 的幀結(jié)構(gòu)也可以看出，在 TCP 的首部沒有表示數(shù)據(jù)長度的字段。
基于上面兩點，在使用 TCP 傳輸數(shù)據(jù)時，才有粘包或者拆包現(xiàn)象發(fā)生的可能。一個數(shù)據(jù)包中包含了發(fā)送端發(fā)送的兩個數(shù)據(jù)包的信息，這種現(xiàn)象即為粘包。
接收端收到了兩個數(shù)據(jù)包，但是這兩個數(shù)據(jù)包要么是不完整的，要么就是多出來一塊，這種情況即發(fā)生了拆包和粘包。拆包和粘包的問題導致接收端在處理的時候會非常困難，因為無法區(qū)分一個完整的數(shù)據(jù)包。
32、TCP 粘包是怎么產(chǎn)生的？

• 發(fā)送方產(chǎn)生粘包
  采用 TCP 協(xié)議傳輸數(shù)據(jù)的客戶端與服務器經(jīng)常是保持一個長連接的狀態(tài)（一次連接發(fā)一次數(shù)據(jù)不存在粘包），雙方在連接不斷開的情況下，可以一直傳輸數(shù)據(jù)。但當發(fā)送的數(shù)據(jù)包過于的小時，那么 TCP 協(xié)議默認的會啟用 Nagle 算法，將這些較小的數(shù)據(jù)包進行合并發(fā)送（緩沖區(qū)數(shù)據(jù)發(fā)送是一個堆壓的過程）；這個合并過程就是在發(fā)送緩沖區(qū)中進行的，也就是說數(shù)據(jù)發(fā)送出來它已經(jīng)是粘包的狀態(tài)了。
• 接收方產(chǎn)生粘包
  接收方采用 TCP 協(xié)議接收數(shù)據(jù)時的過程是這樣的：數(shù)據(jù)到接收方，從網(wǎng)絡模型的下方傳遞至傳輸層，傳輸層的 TCP 協(xié)議處理是將其放置接收緩沖區(qū)，然后由應用層來主動獲取（C 語言用 recv、read 等函數(shù)）；這時會出現(xiàn)一個問題，就是我們在程序中調(diào)用的讀取數(shù)據(jù)函數(shù)不能及時的把緩沖區(qū)中的數(shù)據(jù)拿出來，而下一個數(shù)據(jù)又到來并有一部分放入的緩沖區(qū)末尾，等我們讀取數(shù)據(jù)時就是一個粘包。（放數(shù)據(jù)的速度 > 應用層拿數(shù)據(jù)速度）

33、怎么解決拆包和粘包？

分包機制一般有兩個通用的解決方法：

• 1 特殊字符控制；
• 2 在包頭首都添加數(shù)據(jù)包的長度。
  如果使用 netty 的話，就有專門的編碼器和解碼器解決拆包和粘包問題了。
  tips：UDP 沒有粘包問題，但是有丟包和亂序。不完整的包是不會有的，收到的都是完全正確的包。傳送的數(shù)據(jù)單位協(xié)議是 UDP 報文或用戶數(shù)據(jù)報，發(fā)送的時候既不合并，也不拆分。

34、forward 和 redirect 的區(qū)別？

Forward 和 Redirect 代表了兩種請求轉(zhuǎn)發(fā)方式：直接轉(zhuǎn)發(fā)和間接轉(zhuǎn)發(fā)。

• 直接轉(zhuǎn)發(fā)方式（Forward）：客戶端和瀏覽器只發(fā)出一次請求，Servlet、HTML、JSP 或其它信息資源，由第二個信息資源響應該請求，在請求對象 request 中，保存的對象對于每個信息資源是共享的。
• 間接轉(zhuǎn)發(fā)方式（Redirect）：實際是兩次 HTTP 請求，服務器端在響應第一次請求的時候，讓瀏覽器再向另外一個 URL 發(fā)出請求，從而達到轉(zhuǎn)發(fā)的目的。
  舉個通俗的例子：
  直接轉(zhuǎn)發(fā)就相當于：“A 找 B 借錢，B 說沒有，B 去找 C 借，借到借不到都會把消息傳遞給 A”；
  間接轉(zhuǎn)發(fā)就相當于：”A 找 B 借錢，B 說沒有，讓 A 去找 C 借”。

35、HTTP 方法有哪些？

客戶端發(fā)送的 請求報文 第一行為請求行，包含了方法字段。
GET：獲取資源，當前網(wǎng)絡中絕大部分使用的都是 GET；
HEAD：獲取報文首部，和 GET 方法類似，但是不返回報文實體主體部分；
POST：傳輸實體主體
PUT：上傳文件，由于自身不帶驗證機制，任何人都可以上傳文件，因此存在安全性問題，一般不使用該方法。
PATCH：對資源進行部分修改。PUT 也可以用于修改資源，但是只能完全替代原始資源，PATCH 允許部分修改。
OPTIONS：查詢指定的 URL 支持的方法；
CONNECT：要求在與代理服務器通信時建立隧道。使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡隧道傳輸。
TRACE：追蹤路徑。服務器會將通信路徑返回給客戶端。發(fā)送請求時，在 Max-Forwards 首部字段中填入數(shù)值，每經(jīng)過一個服務器就會減 1，當數(shù)值為 0 時就停止傳輸。通常不會使用 TRACE，并且它容易受到 XST 攻擊（Cross-Site Tracing，跨站追蹤）。

36、在瀏覽器中輸入 URL 地址到顯示主頁的過程？

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

37、DNS 的解析過程？

主機向本地域名服務器的查詢一般都是采用遞歸查詢。所謂遞歸查詢就是：如果主機所詢問的本地域名服務器不知道被查詢的域名的 IP 地址，那么本地域名服務器就以 DNS 客戶的身份，向根域名服務器繼續(xù)發(fā)出查詢請求報文(即替主機繼續(xù)查詢)，而不是讓主機自己進行下一步查詢。因此，遞歸查詢返回的查詢結(jié)果或者是所要查詢的 IP 地址，或者是報錯，表示無法查詢到所需的 IP 地址。
本地域名服務器向根域名服務器的查詢的迭代查詢。迭代查詢的特點：當根域名服務器收到本地域名服務器發(fā)出的迭代查詢請求報文時，要么給出所要查詢的 IP 地址，要么告訴本地服務器：“你下一步應當向哪一個域名服務器進行查詢”。然后讓本地服務器進行后續(xù)的查詢。根域名服務器通常是把自己知道的頂級域名服務器的 IP 地址告訴本地域名服務器，讓本地域名服務器再向頂級域名服務器查詢。頂級域名服務器在收到本地域名服務器的查詢請求后，要么給出所要查詢的 IP 地址，要么告訴本地服務器下一步應當向哪一個權(quán)限域名服務器進行查詢。最后，本地域名服務器得到了所要解析的 IP 地址或報錯，然后把這個結(jié)果返回給發(fā)起查詢的主機。

38、談談你對域名緩存的了解？

為了提高 DNS 查詢效率，并減輕服務器的負荷和減少因特網(wǎng)上的 DNS 查詢報文數(shù)量，在域名服務器中廣泛使用了高速緩存，用來存放最近查詢過的域名以及從何處獲得域名映射信息的記錄。
由于名字到地址的綁定并不經(jīng)常改變，為保持高速緩存中的內(nèi)容正確，域名服務器應為每項內(nèi)容設置計時器并處理超過合理時間的項（例如：每個項目兩天）。當域名服務器已從緩存中刪去某項信息后又被請求查詢該項信息，就必須重新到授權(quán)管理該項的域名服務器綁定信息。當權(quán)限服務器回答一個查詢請求時，在響應中都指明綁定有效存在的時間值。增加此時間值可減少網(wǎng)絡開銷，而減少此時間值可提高域名解析的正確性。
不僅在本地域名服務器中需要高速緩存，在主機中也需要。許多主機在啟動時從本地服務器下載名字和地址的全部數(shù)據(jù)庫，維護存放自己最近使用的域名的高速緩存，并且只在從緩存中找不到名字時才使用域名服務器。維護本地域名服務器數(shù)據(jù)庫的主機應當定期地檢查域名服務器以獲取新的映射信息，而且主機必須從緩存中刪除無效的項。由于域名改動并不頻繁，大多數(shù)網(wǎng)點不需花精力就能維護數(shù)據(jù)庫的一致性。

39、談下你對 HTTP 長連接和短連接的理解？分別應用于哪些場景？

在 HTTP/1.0 中默認使用短連接。也就是說，客戶端和服務器每進行一次 HTTP 操作，就建立一次連接，任務結(jié)束就中斷連接。當客戶端瀏覽器訪問的某個 HTML 或其他類型的 Web 頁中包含有其他的 Web 資源（如：JavaScript 文件、圖像文件、CSS 文件等），每遇到這樣一個 Web 資源，瀏覽器就會重新建立一個 HTTP 會話。
而從 HTTP/1.1 起，默認使用長連接，用以保持連接特性。使用長連接的 HTTP 協(xié)議，會在響應頭加入這行代碼：Connection:keep-alive
在使用長連接的情況下，當一個網(wǎng)頁打開完成后，客戶端和服務器之間用于傳輸 HTTP 數(shù)據(jù)的 TCP 連接不會關閉，客戶端再次訪問這個服務器時，會繼續(xù)使用這一條已經(jīng)建立的連接。
Keep-Alive 不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如：Apache）中設定這個時間。實現(xiàn)長連接需要客戶端和服務端都支持長連接。

40、HTTPS 的工作過程？

• 1 客戶端發(fā)送自己支持的加密規(guī)則給服務器，代表告訴服務器要進行連接了；
• 2 服務器從中選出一套加密算法和 hash 算法以及自己的身份信息（地址等）以證書的形式發(fā)送給瀏覽器，證書中包含服務器信息，加密公鑰，證書的辦法機構(gòu)；
• 3 客戶端收到網(wǎng)站的證書之后要做下面的事情：
  驗證證書的合法性；
  果驗證通過證書，瀏覽器會生成一串隨機數(shù)，并用證書中的公鑰進行加密；
  用約定好的 hash 算法計算握手消息，然后用生成的密鑰進行加密，然后一起發(fā)送給服務器。
• 4 服務器接收到客戶端傳送來的信息，要做下面的事情：
  4.1 用私鑰解析出密碼，用密碼解析握手消息，驗證 hash 值是否和瀏覽器發(fā)來的一致；
  4.2 使用密鑰加密消息；
• 5 如果計算法 hash 值一致，握手成功。

41、HTTP 和 HTTPS 的區(qū)別？

• 開銷：
  HTTPS 協(xié)議需要到 CA 申請證書，一般免費證書很少，需要交費；
• 資源消耗：
  HTTP 是超文本傳輸協(xié)議，信息是明文傳輸，HTTPS 則是具有安全性的 ssl 加密傳輸協(xié)議，需要消耗更多的 CPU 和內(nèi)存資源；
• 端口不同：
  HTTP 和 HTTPS 使用的是完全不同的連接方式，用的端口也不一樣，前者是 80，后者是 443；
• 安全性：
  HTTP 的連接很簡單，是無狀態(tài)的；HTTPS 協(xié)議是由 TSL+HTTP 協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，比 HTTP 協(xié)議安全

42、HTTPS 的優(yōu)缺點？

• 優(yōu)點：
  1 使用 HTTPS 協(xié)議可認證用戶和服務器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務器；
  2 HTTPS 協(xié)議是由 SSL + HTTP 協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，要比 HTTP 協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性；
  3 HTTPS 是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。
• 缺點：
  1 HTTPS 協(xié)議握手階段比較費時，會使頁面的加載時間延長近 50%，增加 10% 到 20% 的耗電；
  2 HTTPS 連接緩存不如 HTTP 高效，會增加數(shù)據(jù)開銷和功耗，甚至已有的安全措施也會因此而受到影響；
  3 SSL 證書需要錢，功能越強大的證書費用越高，個人網(wǎng)站、小網(wǎng)站沒有必要一般不會用；
  4 SSL 證書通常需要綁定 IP，不能在同一 IP 上綁定多個域名，IPv4 資源不可能支撐這個消耗；
  5 HTTPS 協(xié)議的加密范圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什么作用。最關鍵的，SSL 證書的信用鏈體系并不安全，特別是在某些國家可以控制 CA 根證書的情況下，中間人攻擊一樣可行。

43、什么是數(shù)字簽名？

為了避免數(shù)據(jù)在傳輸過程中被替換，比如黑客修改了你的報文內(nèi)容，但是你并不知道，所以我們讓發(fā)送端做一個數(shù)字簽名，把數(shù)據(jù)的摘要消息進行一個加密，比如 MD5，得到一個簽名，和數(shù)據(jù)一起發(fā)送。然后接收端把數(shù)據(jù)摘要進行 MD5 加密，如果和簽名一樣，則說明數(shù)據(jù)確實是真的。

44、什么是數(shù)字證書？

對稱加密中，雙方使用公鑰進行解密。雖然數(shù)字簽名可以保證數(shù)據(jù)不被替換，但是數(shù)據(jù)是由公鑰加密的，如果公鑰也被替換，則仍然可以偽造數(shù)據(jù)，因為用戶不知道對方提供的公鑰其實是假的。所以為了保證發(fā)送方的公鑰是真的，CA 證書機構(gòu)會負責頒發(fā)一個證書，里面的公鑰保證是真的，用戶請求服務器時，服務器將證書發(fā)給用戶，這個證書是經(jīng)由系統(tǒng)內(nèi)置證書的備案的。

45、Cookie 和 Session 有什么區(qū)別？

• 1、由于HTTP協(xié)議是無狀態(tài)的協(xié)議，所以服務端需要記錄用戶的狀態(tài)時，就需要用某種機制來識具體的用戶，這個機制就是Session.典型的場景比如購物車。
  當你點擊下單按鈕時，由于HTTP協(xié)議無狀態(tài)，所以并不知道是哪個用戶操作的，所以服務端要為特定的用戶創(chuàng)建了特定的Session，用用于標識這個用戶，并且跟蹤用戶，這樣才知道購物車里面有幾本書。
  這個Session是保存在服務端的，有一個唯一標識。在服務端保存Session的方法很多，內(nèi)存、數(shù)據(jù)庫、文件都有。集群的時候也要考慮Session的轉(zhuǎn)移，在大型的網(wǎng)站，一般會有專門的Session服務器集群，用來保存用戶會話，這個時候 Session 信息都是放在內(nèi)存的，使用一些緩存服務比如Memcached之類的來放 Session。
• 2、思考一下服務端如何識別特定的客戶？這個時候Cookie就登場了。每次HTTP請求的時候，客戶端都會發(fā)送相應的Cookie信息到服務端。實際上大多數(shù)的應用都是用 Cookie 來實現(xiàn)Session跟蹤的，第一次創(chuàng)建Session的時候，服務端會在HTTP協(xié)議中告訴客戶端，需要在 Cookie 里面記錄一個Session ID，以后每次請求把這個會話ID發(fā)送到服務器，我就知道你是誰了。
  有人問，如果客戶端的瀏覽器禁用了 Cookie 怎么辦？一般這種情況下，會使用一種叫做URL重寫的技術(shù)來進行會話跟蹤，即每次HTTP交互，URL后面都會被附加上一個諸如 sid=xxxxx 這樣的參數(shù)，服務端據(jù)此來識別用戶。
• 3、Cookie其實還可以用在一些方便用戶的場景下，設想你某次登陸過一個網(wǎng)站，下次登錄的時候不想再次輸入賬號了，怎么辦？這個信息可以寫到Cookie里面，訪問網(wǎng)站的時候，網(wǎng)站頁面的腳本可以讀取這個信息，就自動幫你把用戶名給填了，能夠方便一下用戶。這也是Cookie名稱的由來，給用戶的一點甜頭。
• 總結(jié)如下：
  Session是在服務端保存的一個數(shù)據(jù)結(jié)構(gòu)，用來跟蹤用戶的狀態(tài)，這個數(shù)據(jù)可以保存在集群、數(shù)據(jù)庫、文件中。
  Cookie是客戶端保存用戶信息的一種機制，用來記錄用戶的一些信息，也是實現(xiàn)Session的一種方式。