答：TCP 提供一種面向連接的、可靠的字節(jié)流服務(wù)。其中，面向連接意味著兩個(gè)使用 TCP 的應(yīng)用（通常是一個(gè)客戶和一個(gè)服務(wù)器）在彼此交換數(shù)據(jù)之前必須先建立一個(gè) TCP 連接。在一個(gè) TCP 連接中，僅有兩方進(jìn)行彼此通信；而字節(jié)流服務(wù)意味著兩個(gè)應(yīng)用程序通過(guò) TCP 鏈接交換 8 bit 字節(jié)構(gòu)成的字節(jié)流，TCP 不在字節(jié)流中插入記錄標(biāo)識(shí)符。

對(duì)于可靠性，TCP通過(guò)以下方式進(jìn)行保證：

數(shù)據(jù)包校驗(yàn)：目的是檢測(cè)數(shù)據(jù)在傳輸過(guò)程中的任何變化，若校驗(yàn)出包有錯(cuò)，則丟棄報(bào)文段并且不給出響應(yīng)，這時(shí)TCP發(fā)送數(shù)據(jù)端超時(shí)后會(huì)重發(fā)數(shù)據(jù)；

對(duì)失序數(shù)據(jù)包重排序：既然TCP報(bào)文段作為IP數(shù)據(jù)報(bào)來(lái)傳輸，而IP數(shù)據(jù)報(bào)的到達(dá)可能會(huì)失序，因此TCP報(bào)文段的到達(dá)也可能會(huì)失序。TCP將對(duì)失序數(shù)據(jù)進(jìn)行重新排序，然后才交給應(yīng)用層；

丟棄重復(fù)數(shù)據(jù)：對(duì)于重復(fù)數(shù)據(jù)，能夠丟棄重復(fù)數(shù)據(jù)；

應(yīng)答機(jī)制：當(dāng)TCP收到發(fā)自TCP連接另一端的數(shù)據(jù)，它將發(fā)送一個(gè)確認(rèn)。這個(gè)確認(rèn)不是立即發(fā)送，通常將推遲幾分之一秒；

超時(shí)重發(fā)：當(dāng)TCP發(fā)出一個(gè)段后，它啟動(dòng)一個(gè)定時(shí)器，等待目的端確認(rèn)收到這個(gè)報(bào)文段。如果不能及時(shí)收到一個(gè)確認(rèn)，將重發(fā)這個(gè)報(bào)文段；

流量控制：TCP連接的每一方都有固定大小的緩沖空間。TCP的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)，這可以防止較快主機(jī)致使較慢主機(jī)的緩沖區(qū)溢出，這就是流量控制。TCP使用的流量控制協(xié)議是可變大小的滑動(dòng)窗口協(xié)議。

客戶端不斷進(jìn)行請(qǐng)求鏈接會(huì)怎樣？DDos(Distributed Denial of Service)攻擊？

答：服務(wù)器端會(huì)為每個(gè)請(qǐng)求創(chuàng)建一個(gè)鏈接，并向其發(fā)送確認(rèn)報(bào)文，然后等待客戶端進(jìn)行確認(rèn)

(1). DDos 攻擊：

客戶端向服務(wù)端發(fā)送請(qǐng)求鏈接數(shù)據(jù)包

服務(wù)端向客戶端發(fā)送確認(rèn)數(shù)據(jù)包

客戶端不向服務(wù)端發(fā)送確認(rèn)數(shù)據(jù)包，服務(wù)器一直等待來(lái)自客戶端的確認(rèn)

(2). DDos 預(yù)防：（沒(méi)有徹底根治的辦法，除非不使用TCP）

限制同時(shí)打開(kāi)SYN半鏈接的數(shù)目

縮短SYN半鏈接的Time out 時(shí)間

關(guān)閉不必要的服務(wù)

TCP與UDP的區(qū)別

答：TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)協(xié)議屬于傳輸層協(xié)議，它們之間的區(qū)別包括：

TCP是面向連接的，UDP是無(wú)連接的；

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

TCP只支持點(diǎn)對(duì)點(diǎn)通信，UDP支持一對(duì)一、一對(duì)多、多對(duì)一、多對(duì)多的通信模式；

TCP是面向字節(jié)流的，UDP是面向報(bào)文的；

TCP有擁塞控制機(jī)制;UDP沒(méi)有擁塞控制，適合媒體通信；

TCP首部開(kāi)銷(xiāo)(20個(gè)字節(jié))比UDP的首部開(kāi)銷(xiāo)(8個(gè)字節(jié))要大；

UDP其實(shí)就是在IP報(bào)文中添加了端口信息，使數(shù)據(jù)到達(dá)主機(jī)后送達(dá)至相應(yīng)端口的應(yīng)用程序。

UDP傳輸速度更快，因?yàn)楹雎粤税踩?，效率?/p>

TCP和UDP分別對(duì)應(yīng)的常見(jiàn)應(yīng)用層協(xié)議

(1). TCP 對(duì)應(yīng)的應(yīng)用層協(xié)議：

FTP：定義了文件傳輸協(xié)議，使用21端口。常說(shuō)某某計(jì)算機(jī)開(kāi)了FTP服務(wù)便是啟動(dòng)了文件傳輸服務(wù)。下載文件，上傳主頁(yè)，都要用到FTP服務(wù)。

HTTP：從Web服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。

SMTP：定義了簡(jiǎn)單郵件傳送協(xié)議，現(xiàn)在很多郵件服務(wù)器都用的是這個(gè)協(xié)議，用于發(fā)送郵件。如常見(jiàn)的免費(fèi)郵件服務(wù)中用的就是這個(gè)郵件服務(wù)端口，所以在電子郵件設(shè)置-中?？吹接羞@么SMTP端口設(shè)置這個(gè)欄，服務(wù)器開(kāi)放的是25號(hào)端口。

POP3：它是和SMTP對(duì)應(yīng)，POP3用于接收郵件。通常情況下，POP3協(xié)議所用的是110端口。也是說(shuō)，只要你有相應(yīng)的使用POP3協(xié)議的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陸進(jìn)郵箱界面，直接用郵件程序就可以收到郵件（如是163郵箱就沒(méi)有必要先進(jìn)入網(wǎng)易網(wǎng)站，再進(jìn)入自己的郵-箱來(lái)收信）。

(2). UDP 對(duì)應(yīng)的應(yīng)用層協(xié)議：

DNS：用于域名解析服務(wù)，將域名地址轉(zhuǎn)換為IP地址。DNS用的是53號(hào)端口。

SNMP：簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議，使用161號(hào)端口，是用來(lái)管理網(wǎng)絡(luò)設(shè)備的。由于網(wǎng)絡(luò)設(shè)備很多，無(wú)連接的服務(wù)就體現(xiàn)出其優(yōu)勢(shì)。

TFTP(Trival File Transfer Protocal)：簡(jiǎn)單文件傳輸協(xié)議，該協(xié)議在熟知端口69上使用UDP服務(wù)

TCP 的擁塞避免機(jī)制

擁塞：對(duì)資源的需求超過(guò)了可用的資源。若網(wǎng)絡(luò)中許多資源同時(shí)供應(yīng)不足，網(wǎng)絡(luò)的性能就要明顯變壞，整個(gè)網(wǎng)絡(luò)的吞吐量隨之負(fù)荷的增大而下降。

擁塞控制：防止過(guò)多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，使得網(wǎng)絡(luò)中的路由器或鏈路不致過(guò)載。

擁塞控制的方法：

慢啟動(dòng)：不要一開(kāi)始就發(fā)送大量的數(shù)據(jù)，先探測(cè)一下網(wǎng)絡(luò)的擁塞程度，也就是說(shuō)由小到大逐漸增加擁塞窗口的大小;

擁塞避免：擁塞避免算法讓擁塞窗口緩慢增長(zhǎng)，即每經(jīng)過(guò)一個(gè)往返時(shí)間RTT就把發(fā)送方的擁塞窗口cwnd加1，而不是加倍，這樣擁塞窗口按線性規(guī)律緩慢增長(zhǎng)。

快重傳：快重傳要求接收方在收到一個(gè) 失序的報(bào)文段 后就立即發(fā)出 重復(fù)確認(rèn)（為的是使發(fā)送方及早知道有報(bào)文段沒(méi)有到達(dá)對(duì)方）而不要等到自己發(fā)送數(shù)據(jù)時(shí)捎帶確認(rèn)?？熘貍魉惴ㄒ?guī)定，發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對(duì)方尚未收到的報(bào)文段，而不必繼續(xù)等待設(shè)置的重傳計(jì)時(shí)器時(shí)間到期。

快恢復(fù)：快重傳配合使用的還有快恢復(fù)算法，當(dāng)發(fā)送方連續(xù)收到三個(gè)重復(fù)確認(rèn)時(shí)，就執(zhí)行“乘法減小”算法，把ssthresh門(mén)限減半，但是接下去并不執(zhí)行慢開(kāi)始算法：因?yàn)槿绻W(wǎng)絡(luò)出現(xiàn)擁塞的話就不會(huì)收到好幾個(gè)重復(fù)的確認(rèn)，所以發(fā)送方現(xiàn)在認(rèn)為網(wǎng)絡(luò)可能沒(méi)有出現(xiàn)擁塞。所以此時(shí)不執(zhí)行慢開(kāi)始算法，而是將cwnd設(shè)置為ssthresh的大小，然后執(zhí)行擁塞避免算法。

HTTP

Http和Https的區(qū)別？

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

端口不同：Http與Http使用不同的連接方式，用的端口也不一樣，前者是80，后者是443；

資源消耗：和HTTP通信相比，Https通信會(huì)由于加減密處理消耗更多的CPU和內(nèi)存資源；

開(kāi)銷(xiāo)：Https通信需要證書(shū)，而證書(shū)一般需要向認(rèn)證機(jī)構(gòu)購(gòu)買(mǎi)；

Https的加密機(jī)制是一種共享密鑰加密（對(duì)稱(chēng)加密）和公開(kāi)密鑰加密（非對(duì)稱(chēng)加密）并用的混合加密機(jī)制。

對(duì)稱(chēng)加密與非對(duì)稱(chēng)加密

對(duì)稱(chēng)密鑰加密是指加密和解密使用同一個(gè)密鑰的方式，這種方式存在的最大問(wèn)題就是密鑰發(fā)送問(wèn)題，即如何安全地將密鑰發(fā)給對(duì)方；而非對(duì)稱(chēng)加密是指使用一對(duì)非對(duì)稱(chēng)密鑰，即公鑰和私鑰，公鑰可以隨意發(fā)布，但私鑰只有自己知道。發(fā)送密文的一方使用對(duì)方的公鑰進(jìn)行加密處理，對(duì)方接收到加密信息后，使用自己的私鑰進(jìn)行解密。

由于非對(duì)稱(chēng)加密的方式不需要發(fā)送用來(lái)解密的私鑰，所以可以保證安全性；但是和對(duì)稱(chēng)加密比起來(lái)，它非常的慢，所以我們還是要用對(duì)稱(chēng)加密來(lái)傳送消息，但對(duì)稱(chēng)加密所使用的密鑰我們可以通過(guò)非對(duì)稱(chēng)加密的方式發(fā)送出去。

https加密機(jī)制

當(dāng)無(wú)加密的http通信被第三方攔截，第三方攻擊者即可隨意篡改報(bào)文，攻擊方法運(yùn)用最廣泛的莫過(guò)于dns劫持，http網(wǎng)站之所以會(huì)被無(wú)端掛廣告，正是因?yàn)檫\(yùn)營(yíng)商在通信過(guò)程中修改了返回的報(bào)文，在返回的數(shù)據(jù)中添加了廣告代碼。

正是出于防止篡改的目的，https通信過(guò)程發(fā)生了以下的步驟：

1.客戶端發(fā)送初始請(qǐng)求該請(qǐng)求包含客戶端支持的加密算法列表供服務(wù)器選擇，出于性能考慮，這些算法一般來(lái)說(shuō)都是對(duì)稱(chēng)加密算法

2.服務(wù)器接收請(qǐng)求，返回服務(wù)器生成的數(shù)字證書(shū)和選擇的加密算法，此時(shí)公鑰作為證書(shū)的一部分一并傳給客戶端

3.客戶端接收服務(wù)器傳回的證書(shū)和加密算法，此時(shí)，客戶端，例如瀏覽器會(huì)首先校驗(yàn)證書(shū)的合法性（校驗(yàn)方法后續(xù)詳細(xì)說(shuō)），如果此時(shí)校驗(yàn)失敗，客戶端會(huì)立刻發(fā)出警告，由用戶決定是否繼續(xù)，如果校驗(yàn)成功，此時(shí)客戶端則會(huì)針對(duì)服務(wù)器傳回的加密算法，生成一個(gè)隨機(jī)的密鑰，并用公鑰加密之后，發(fā)送給服務(wù)端

4.服務(wù)端接收到客戶端傳回的隨機(jī)密鑰之后，用持有的私鑰進(jìn)行解密，取得客戶端發(fā)送的隨機(jī)密鑰，此時(shí)服務(wù)端會(huì)使用當(dāng)前密鑰，對(duì)數(shù)據(jù)進(jìn)行對(duì)稱(chēng)加密之后傳給客戶端

5.客戶端取得加密數(shù)據(jù)之后，用上一個(gè)回合生成的密鑰解開(kāi)密文，取得響應(yīng)數(shù)據(jù)

6.客戶端和服務(wù)端會(huì)持續(xù)使用約定的密鑰對(duì)數(shù)據(jù)進(jìn)行加密交互

關(guān)于證書(shū)認(rèn)證

那么，客戶端是怎么校驗(yàn)當(dāng)前的證書(shū)是否合法的呢，包括以下幾個(gè)方面

1.證書(shū)有效日期

當(dāng)前日期如果已經(jīng)超過(guò)了有效期或者證書(shū)尚未被激活，則有效性驗(yàn)證失敗

2.證書(shū)頒發(fā)者可信度

客戶端會(huì)維護(hù)一個(gè)證書(shū)機(jī)構(gòu)信任列表，可信任的機(jī)構(gòu)（如CA）頒發(fā)的證書(shū)會(huì)被客戶端所信任，用戶自主導(dǎo)入的證書(shū)，也會(huì)被客戶端所信任，當(dāng)證書(shū)頒發(fā)機(jī)構(gòu)不被信任時(shí)，有效性驗(yàn)證失敗

3.簽名校驗(yàn)

這也是最關(guān)鍵的一步，上文提到，服務(wù)端對(duì)證書(shū)簽名的時(shí)候是對(duì)報(bào)文用私鑰進(jìn)行加密，此時(shí)客戶端需要用公鑰對(duì)簽名進(jìn)行解密，然后跟報(bào)文的關(guān)鍵字進(jìn)行比較，有任何一項(xiàng)匹配不上，都會(huì)導(dǎo)致有效性驗(yàn)證失敗，這一步主要是防止請(qǐng)求被篡改

4.站點(diǎn)身份校驗(yàn)

這一步瀏覽器會(huì)校驗(yàn)證書(shū)中的域名和當(dāng)前客戶端所對(duì)話的服務(wù)端的域名是否匹配，防止服務(wù)器復(fù)制他人的證書(shū)，如果不匹配，校驗(yàn)失敗

GET 與 POST 的區(qū)別

答：GET與POST是我們常用的兩種HTTP Method，二者之間的區(qū)別主要包括如下五個(gè)方面：

(1). 從功能上講，GET一般用來(lái)從服務(wù)器上獲取資源，POST一般用來(lái)更新服務(wù)器上的資源；

(2). 從REST服務(wù)角度上說(shuō)，GET是冪等的，即讀取同一個(gè)資源，總是得到相同的數(shù)據(jù)，而POST不是冪等的，因?yàn)槊看握?qǐng)求對(duì)資源的改變并不是相同的；進(jìn)一步地，GET不會(huì)改變服務(wù)器上的資源，而POST會(huì)對(duì)服務(wù)器資源進(jìn)行改變；

(3). 從請(qǐng)求參數(shù)形式上看，GET請(qǐng)求的數(shù)據(jù)會(huì)附在URL之后，即將請(qǐng)求數(shù)據(jù)放置在HTTP報(bào)文的 請(qǐng)求頭 中，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連。特別地，如果數(shù)據(jù)是英文字母/數(shù)字，原樣發(fā)送；否則，會(huì)將其編碼為 application/x-www-form-urlencoded MIME 字符串(如果是空格，轉(zhuǎn)換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號(hào)以16進(jìn)制表示的ASCII)；而POST請(qǐng)求會(huì)把提交的數(shù)據(jù)則放置在是HTTP請(qǐng)求報(bào)文的 請(qǐng)求體 中。

(4). 就安全性而言，POST的安全性要比GET的安全性高，因?yàn)镚ET請(qǐng)求提交的數(shù)據(jù)將明文出現(xiàn)在URL上，而且POST請(qǐng)求參數(shù)則被包裝到請(qǐng)求體中，相對(duì)更安全。

(5). 從請(qǐng)求的大小看，GET請(qǐng)求的長(zhǎng)度受限于瀏覽器或服務(wù)器對(duì)URL長(zhǎng)度的限制，允許發(fā)送的數(shù)據(jù)量比較小，而POST請(qǐng)求則是沒(méi)有大小限制的。

重點(diǎn)： 瀏覽器中輸入：“www.xxx.com” 之后都發(fā)生了什么？請(qǐng)?jiān)敿?xì)闡述

1.DNS解析由域名→IP地址 尋找IP地址的過(guò)程依次經(jīng)過(guò)了瀏覽器緩存、系統(tǒng)緩存、hosts文件、路由器緩存、 遞歸搜索根域名服務(wù)器。

2.建立TCP/IP連接（三次握手具體過(guò)程）

3.由瀏覽器發(fā)送一個(gè)HTTP請(qǐng)求經(jīng)過(guò)路由器的轉(zhuǎn)發(fā)，通過(guò)服務(wù)器的防火墻，該HTTP請(qǐng)求到達(dá)了服務(wù)器

4.服務(wù)器處理該HTTP請(qǐng)求，返回一個(gè)HTML文件

5.瀏覽器解析該HTML文件，并且顯示在瀏覽器端

一次完整的HTTP請(qǐng)求所經(jīng)歷的7個(gè)步驟

1）建立TCP連接

在HTTP工作開(kāi)始之前，Web瀏覽器首先要通過(guò)網(wǎng)絡(luò)與Web服務(wù)器建立連接，該連接是通過(guò)TCP來(lái)完成的，該協(xié)議與IP協(xié)議共同構(gòu)建Internet，即著名的TCP/IP協(xié)議族，因此Internet又被稱(chēng)作是TCP/IP網(wǎng)絡(luò)。HTTP是比TCP更高層次的應(yīng)用層協(xié)議，根據(jù)規(guī)則，只有低層協(xié)議建立之后才能進(jìn)行更高層協(xié)議的連接，因此，首先要建立TCP連接，一般TCP連接的端口號(hào)是80。

2）Web瀏覽器向Web服務(wù)器發(fā)送請(qǐng)求命令

一旦建立了TCP連接，Web瀏覽器就會(huì)向Web服務(wù)器發(fā)送請(qǐng)求命令。例如：GET/sample/hello.jsp HTTP/1.1。

3）Web瀏覽器發(fā)送請(qǐng)求頭信息

瀏覽器發(fā)送其請(qǐng)求命令之后，還要以頭信息的形式向Web服務(wù)器發(fā)送一些別的信息，之后瀏覽器發(fā)送了一空白行來(lái)通知服務(wù)器，它已經(jīng)結(jié)束了該頭信息的發(fā)送。

4）Web服務(wù)器應(yīng)答

客戶機(jī)向服務(wù)器發(fā)出請(qǐng)求后，服務(wù)器會(huì)客戶機(jī)回送應(yīng)答， HTTP/1.1 200 OK ，應(yīng)答的第一部分是協(xié)議的版本號(hào)和應(yīng)答狀態(tài)碼。

5）Web服務(wù)器發(fā)送應(yīng)答頭信息

正如客戶端會(huì)隨同請(qǐng)求發(fā)送關(guān)于自身的信息一樣，服務(wù)器也會(huì)隨同應(yīng)答向用戶發(fā)送關(guān)于它自己的數(shù)據(jù)及被請(qǐng)求的文檔。

6）Web服務(wù)器向?yàn)g覽器發(fā)送數(shù)據(jù)

Web服務(wù)器向?yàn)g覽器發(fā)送頭信息后，它會(huì)發(fā)送一個(gè)空白行來(lái)表示頭信息的發(fā)送到此為結(jié)束，接著，它就以Content-Type應(yīng)答頭信息所描述的格式發(fā)送用戶所請(qǐng)求的實(shí)際數(shù)據(jù)。

7）Web服務(wù)器關(guān)閉TCP連接

一般情況下，一旦Web服務(wù)器向?yàn)g覽器發(fā)送了請(qǐng)求數(shù)據(jù)，它就要關(guān)閉TCP連接，然后如果瀏覽器或者服務(wù)器在其頭信息加入了這行代碼：Connection:keep-alive
TCP連接在發(fā)送后將仍然保持打開(kāi)狀態(tài)，于是，瀏覽器可以繼續(xù)通過(guò)相同的連接發(fā)送請(qǐng)求。保持連接節(jié)省了為每個(gè)請(qǐng)求建立新連接所需的時(shí)間，還節(jié)約了網(wǎng)絡(luò)帶寬。

什么是 HTTP 協(xié)議無(wú)狀態(tài)協(xié)議？怎么解決Http協(xié)議無(wú)狀態(tài)協(xié)議?

答：HTTP 是一個(gè)無(wú)狀態(tài)的協(xié)議，也就是沒(méi)有記憶力，這意味著每一次的請(qǐng)求都是獨(dú)立的，缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須要重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就很快。

HTTP 的這種特性有優(yōu)點(diǎn)也有缺點(diǎn)：

優(yōu)點(diǎn)：解放了服務(wù)器，每一次的請(qǐng)求“點(diǎn)到為止”，不會(huì)造成不必要的連接占用

缺點(diǎn)：每次請(qǐng)求會(huì)傳輸大量重復(fù)的內(nèi)容信息，并且，在請(qǐng)求之間無(wú)法實(shí)現(xiàn)數(shù)據(jù)的共享

解決方案：

1.使用參數(shù)傳遞機(jī)制：
將參數(shù)拼接在請(qǐng)求的 URL 后面，實(shí)現(xiàn)數(shù)據(jù)的傳遞（GET方式），例如：/param/list?username=wmyskxz
問(wèn)題：可以解決數(shù)據(jù)共享的問(wèn)題，但是這種方式一不安全，二數(shù)據(jù)允許傳輸量只有1kb

2.使用 Cookie 技術(shù)

3.使用 Session 技術(shù)

Session、Cookie 與 Application

Cookie和Session都是客戶端與服務(wù)器之間保持狀態(tài)的解決方案，具體來(lái)說(shuō)，cookie機(jī)制采用的是在客戶端保持狀態(tài)的方案，而session機(jī)制采用的是在服務(wù)器端保持狀態(tài)的方案。

(1). Cookie 及其相關(guān) API ：

Cookie實(shí)際上是一小段的文本信息?？蛻舳苏?qǐng)求服務(wù)器，如果服務(wù)器需要記錄該用戶狀態(tài)，就使用response向客戶端瀏覽器頒發(fā)一個(gè)Cookie，而客戶端瀏覽器會(huì)把Cookie保存起來(lái)。當(dāng)瀏覽器再請(qǐng)求該網(wǎng)站時(shí)，瀏覽器把請(qǐng)求的網(wǎng)址連同該Cookie一同提交給服務(wù)器，服務(wù)器檢查該Cookie，以此來(lái)辨認(rèn)用戶狀態(tài)。服務(wù)器還可以根據(jù)需要修改Cookie的內(nèi)容。

(2). Session 及其相關(guān) API：

同樣地，會(huì)話狀態(tài)也可以保存在服務(wù)器端?？蛻舳苏?qǐng)求服務(wù)器，如果服務(wù)器記錄該用戶狀態(tài)，就獲取Session來(lái)保存狀態(tài)，這時(shí)，如果服務(wù)器已經(jīng)為此客戶端創(chuàng)建過(guò)session，服務(wù)器就按照sessionid把這個(gè)session檢索出來(lái)使用；如果客戶端請(qǐng)求不包含sessionid，則為此客戶端創(chuàng)建一個(gè)session并且生成一個(gè)與此session相關(guān)聯(lián)的sessionid，并將這個(gè)sessionid在本次響應(yīng)中返回給客戶端保存。保存這個(gè)sessionid的方式可以采用 cookie機(jī)制 ，這樣在交互過(guò)程中瀏覽器可以自動(dòng)的按照規(guī)則把這個(gè)標(biāo)識(shí)發(fā)揮給服務(wù)器；若瀏覽器禁用Cookie的話，可以通過(guò) URL重寫(xiě)機(jī)制 將sessionid傳回服務(wù)器。

(3). Session 與 Cookie 的對(duì)比：

實(shí)現(xiàn)機(jī)制：Session的實(shí)現(xiàn)常常依賴(lài)于Cookie機(jī)制，通過(guò)Cookie機(jī)制回傳SessionID；

大小限制：Cookie有大小限制并且瀏覽器對(duì)每個(gè)站點(diǎn)也有cookie的個(gè)數(shù)限制，Session沒(méi)有大小限制，理論上只與服務(wù)器的內(nèi)存大小有關(guān)；

安全性：Cookie存在安全隱患，通過(guò)攔截或本地文件找得到cookie后可以進(jìn)行攻擊，而Session由于保存在服務(wù)器端，相對(duì)更加安全；

服務(wù)器資源消耗：Session是保存在服務(wù)器端上會(huì)存在一段時(shí)間才會(huì)消失，如果session過(guò)多會(huì)增加服務(wù)器的壓力。

(4). Application：

Application（ServletContext）：與一個(gè)Web應(yīng)用程序相對(duì)應(yīng)，為應(yīng)用程序提供了一個(gè)全局的狀態(tài)，所有客戶都可以使用該狀態(tài)。

常見(jiàn)HTTP狀態(tài)碼

1xx（臨時(shí)響應(yīng)）

2xx（成功）

3xx（重定向）：表示要完成請(qǐng)求需要進(jìn)一步操作

4xx（錯(cuò)誤）：表示請(qǐng)求可能出錯(cuò)，妨礙了服務(wù)器的處理

5xx（服務(wù)器錯(cuò)誤）：表示服務(wù)器在嘗試處理請(qǐng)求時(shí)發(fā)生內(nèi)部錯(cuò)誤

OSI 網(wǎng)絡(luò)體系結(jié)構(gòu)與 TCP/IP 協(xié)議模型

答：OSI 是一個(gè)理論上的網(wǎng)絡(luò)通信模型，而 TCP/IP 則是實(shí)際上的網(wǎng)絡(luò)通信標(biāo)準(zhǔn)。但是，它們的初衷是一樣的，都是為了使得兩臺(tái)計(jì)算機(jī)能夠像兩個(gè)知心朋友那樣能夠互相準(zhǔn)確理解對(duì)方的意思并做出優(yōu)雅的回應(yīng)。

1). 物理層

參考模型的最低層，也是OSI模型的第一層，實(shí)現(xiàn)了相鄰計(jì)算機(jī)節(jié)點(diǎn)之間比特流的透明傳送，并盡可能地屏蔽掉具體傳輸介質(zhì)和物理設(shè)備的差異，使其上層(數(shù)據(jù)鏈路層)不必關(guān)心網(wǎng)絡(luò)的具體傳輸介質(zhì)。

2). 數(shù)據(jù)鏈路層（data link layer）

接收來(lái)自物理層的位流形式的數(shù)據(jù)，并封裝成幀，傳送到上一層；同樣，也將來(lái)自上層的數(shù)據(jù)幀，拆裝為位流形式的數(shù)據(jù)轉(zhuǎn)發(fā)到物理層。這一層在物理層提供的比特流的基礎(chǔ)上，通過(guò)差錯(cuò)控制、流量控制方法，使有差錯(cuò)的物理線路變?yōu)闊o(wú)差錯(cuò)的數(shù)據(jù)鏈路，即提供可靠的通過(guò)物理介質(zhì)傳輸數(shù)據(jù)的方法。

3). 網(wǎng)絡(luò)層

將網(wǎng)絡(luò)地址翻譯成對(duì)應(yīng)的物理地址，并通過(guò)路由選擇算法為分組通過(guò)通信子網(wǎng)選擇最適當(dāng)?shù)穆窂健?/p>

4). 傳輸層（transport layer）

在源端與目的端之間提供可靠的透明數(shù)據(jù)傳輸，使上層服務(wù)用戶不必關(guān)系通信子網(wǎng)的實(shí)現(xiàn)細(xì)節(jié)。在協(xié)議棧中，傳輸層位于網(wǎng)絡(luò)層之上，傳輸層協(xié)議為不同主機(jī)上運(yùn)行的進(jìn)程提供邏輯通信，而網(wǎng)絡(luò)層協(xié)議為不同主機(jī)提供邏輯通信，如下圖所示。

5). 會(huì)話層（Session Layer）

會(huì)話層是OSI模型的第五層，是用戶應(yīng)用程序和網(wǎng)絡(luò)之間的接口，負(fù)責(zé)在網(wǎng)絡(luò)中的兩節(jié)點(diǎn)之間建立、維持和終止通信。

6). 表示層（Presentation Layer）：數(shù)據(jù)的編碼，壓縮和解壓縮，數(shù)據(jù)的加密和解密

表示層是OSI模型的第六層，它對(duì)來(lái)自應(yīng)用層的命令和數(shù)據(jù)進(jìn)行解釋?zhuān)源_保一個(gè)系統(tǒng)的應(yīng)用層所發(fā)送的信息可以被另一個(gè)系統(tǒng)的應(yīng)用層讀取。

7). 應(yīng)用層（Application layer）：為用戶的應(yīng)用進(jìn)程提供網(wǎng)絡(luò)通信服務(wù)

IP地址與物理地址

答：物理地址是數(shù)據(jù)鏈路層和物理層使用的地址，IP地址是網(wǎng)絡(luò)層和以上各層使用的地址，是一種邏輯地址，其中ARP協(xié)議用于IP地址與物理地址的對(duì)應(yīng)。

影響網(wǎng)絡(luò)傳輸?shù)囊蛩赜心男?/strong>