這塊兒有可能也會(huì)問到

一，OSI網(wǎng)絡(luò)七層模型和tcp/ip四層模型（常以筆試形式考察）

①OSI中的上面4層（應(yīng)用層、表示層、會(huì)話層、傳輸層）為高層，定義了程序的功能；

下面3層（網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層、物理層）為底層，主要是處理面向網(wǎng)絡(luò)端到端的數(shù)據(jù)流。

②四層模型?tcp/ip這個(gè)協(xié)議遵守一個(gè)四層的模型概念:應(yīng)用層、傳輸層、互聯(lián)層和網(wǎng)絡(luò)接口層。

二，TCP和UDP協(xié)議區(qū)別

這倆是傳輸層的兩個(gè)協(xié)議，他們之間的主要區(qū)別是：

1，TCP是面向連接的 ，類似于打電話要先撥號(hào)一樣的，而udp是面向無連接的，在發(fā)送數(shù)據(jù)之前呢是不需要建立連接的，所以TCP的傳送速度要慢

2，TCP是一對(duì)一連接的，可靠的協(xié)議，保證傳輸數(shù)據(jù)的完整性正確性，不丟包不重復(fù)，而且是有序的，但是udp就是不可靠的，它只要交付就可以了，不會(huì)去保證數(shù)據(jù)是否正確到達(dá)

3，安全性，TCP的安全性比udp要低，漏洞比較多，容易受到攻擊

應(yīng)用：

TCP的使用場(chǎng)景主要是我們平時(shí)登錄QQ，傳文件，發(fā)郵件這樣的場(chǎng)景

而udp的實(shí)時(shí)性比較高，所以我們用的微信視頻通話這樣的場(chǎng)景

三，TCP協(xié)議可靠的原因

①超時(shí)重傳 發(fā)送數(shù)據(jù)時(shí)設(shè)置一個(gè)重傳定時(shí)器，來監(jiān)測(cè)數(shù)據(jù)丟失狀態(tài)，如果說時(shí)間已經(jīng)到了，但還沒有收到數(shù)據(jù)，就判定這個(gè)數(shù)據(jù)包已經(jīng)丟失

②流量控制 滑動(dòng)窗口協(xié)議?

③擁塞控制 有四個(gè)核心算法，慢啟動(dòng)，擁塞避免，快速重傳，快速恢復(fù)

四，TCP協(xié)議三次握手，四次揮手

三次握手的原因是 讓客戶端和服務(wù)端都知道對(duì)方具備收和發(fā)的能力

clientA ?---syn---> clientB ? //clientB 此時(shí)已經(jīng)知道了clientA具備發(fā)送的能力 clientA <----syn-----clientB ?//clientA 此時(shí)已經(jīng)知道clientB具備收和發(fā)的能力? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 但是此時(shí)clientB還不知道clientA是否具備收的能力?

clientA ----ack----> clientB ?//B收到了syn 知道了A具備收的能力

四次揮手的原因:

clientA ?---fin---> clientB ? //clientA 給B發(fā)送關(guān)閉連接

clientA <----fin-----clientB ?//clientB 告訴對(duì)方自己可以關(guān)閉了，但是在關(guān)閉之? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??前要把自己發(fā)送隊(duì)列的數(shù)據(jù)給對(duì)端發(fā)了?

clientA <----ack----- clientB ?//自己發(fā)送隊(duì)列數(shù)據(jù)給對(duì)端發(fā)完，給對(duì)端說可以關(guān)了 clientA ----ack------> clientB //結(jié)束揮手?

至于原因:讓tcp關(guān)閉連接可以保證自己可靠的關(guān)閉連接

五，HTTPS和HTTP的區(qū)別主要如下：

1、https協(xié)議需要到ca申請(qǐng)證書，一般免費(fèi)證書較少，因而需要一定費(fèi)用。

2、http是超文本傳輸協(xié)議，信息是明文傳輸，安全性差，https則是具有安全性的ssl加密傳輸協(xié)議。

3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

4、http的連接很簡(jiǎn)單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

六，HTTP超文本傳輸協(xié)議構(gòu)成（明文傳輸，不加密）

http協(xié)議的內(nèi)容分為：請(qǐng)求和響應(yīng)

HTTP的請(qǐng)求行結(jié)構(gòu)：請(qǐng)求方式+請(qǐng)求地址（url）+請(qǐng)求協(xié)議（http）

HTTP的響應(yīng)行結(jié)構(gòu)：響應(yīng)協(xié)議+響應(yīng)碼+響應(yīng)信息

HTTP請(qǐng)求中斷的原因：

網(wǎng)絡(luò)擁堵，網(wǎng)絡(luò)斷了或者請(qǐng)求超時(shí)，瀏覽器或者服務(wù)器出現(xiàn)問題

請(qǐng)求 包括請(qǐng)求行、請(qǐng)求頭、請(qǐng)求正文。

請(qǐng)求行的組成：請(qǐng)求方式、url字段、http版本。

常見的請(qǐng)求方式有：post、get、put、delete、trace、connect、options。

url字段的組成：http://ip地址或域名(www.baid.com)【：端口，是8080就可以省略】/路徑？參數(shù)1=值1&參數(shù)2=值2

請(qǐng)求頭：請(qǐng)求頭部通知服務(wù)器有關(guān)于客戶端請(qǐng)求的信息。常用的請(qǐng)求頭有：User-Agent：產(chǎn)生請(qǐng)求的瀏覽器類型，Accept：客戶端可識(shí)別的內(nèi)容類型列表，Content-Type：請(qǐng)求體的MIME類型。

請(qǐng)求正文：get請(qǐng)求沒有請(qǐng)求正文，post請(qǐng)求有請(qǐng)求正文，請(qǐng)求正文類型比較豐富，大小也是由當(dāng)前的數(shù)據(jù)決定的。

響應(yīng) 包括響應(yīng)行、響應(yīng)頭、響應(yīng)正文。

響應(yīng)行的組成：響應(yīng)信息、響應(yīng)狀態(tài)碼、http版本。

響應(yīng)信息：如：OK、Found

響應(yīng)狀態(tài)碼：

1xx：通知信息，請(qǐng)求被接收需要進(jìn)行下一步處理；

2xx：請(qǐng)求被成功處理，例如：200；

3xx：請(qǐng)求被重定向；301為永久重定向，302為臨時(shí)重定向

4xx：客戶端請(qǐng)求錯(cuò)誤；400：其含義是你訪問的頁(yè)面域名不存在或者請(qǐng)求錯(cuò)誤，403：請(qǐng)求被禁止，404：服務(wù)器無法找到客戶端請(qǐng)求的資源

5xx：服務(wù)器錯(cuò)誤；500：服務(wù)器內(nèi)部錯(cuò)誤

響應(yīng)頭：響應(yīng)頭用于服務(wù)器向客戶端描述服務(wù)器的基本信息，以及數(shù)據(jù)的描述：例如瀏覽器類型等

響應(yīng)正文：類型比較豐富，有圖片、文本、視頻等

七，常見狀態(tài)碼

• 200 OK：請(qǐng)求成功，服務(wù)器正常處理請(qǐng)求，并返回請(qǐng)求的資源。

• 201 Created：請(qǐng)求成功，服務(wù)器已經(jīng)成功創(chuàng)建了新的資源，并將其URI返回給客戶端。

• 204 No Content：請(qǐng)求成功，服務(wù)器已經(jīng)成功處理了請(qǐng)求，但沒有返回任何實(shí)體內(nèi)容。

• 301 Moved Permanently：請(qǐng)求的資源已經(jīng)被永久移動(dòng)到新的URI，客戶端需要更新URI并重新發(fā)送請(qǐng)求。

• 302 Found：請(qǐng)求的資源已經(jīng)臨時(shí)移動(dòng)到新的URI，客戶端需要更新URI并重新發(fā)送請(qǐng)求。

• 304 Not Modified：請(qǐng)求的資源沒有修改，客戶端可以直接使用本地緩存的版本。

• 400 Bad Request：請(qǐng)求有誤，服務(wù)器無法處理該請(qǐng)求。

• 401 Unauthorized：請(qǐng)求需要身份驗(yàn)證，客戶端需要提供有效的身份認(rèn)證信息。

• 403 Forbidden：請(qǐng)求被服務(wù)器拒絕，客戶端沒有權(quán)限訪問該資源。

• 500 Internal Server Error：服務(wù)器內(nèi)部錯(cuò)誤，無法完成請(qǐng)求。

• 503 Service Unavailable：服務(wù)器暫時(shí)無法處理請(qǐng)求，通常是由于服務(wù)器過載或維護(hù)等原因。

八，GET 和 POST區(qū)別

get是獲取數(shù)據(jù)的,而post是提交數(shù)據(jù)的，?用于修改服務(wù)器上的數(shù)據(jù)，有副作用

GET不如POST安全，雖然兩者都可以是明文，因?yàn)镻OST用body傳輸數(shù)據(jù)，而GET用url傳輸，更加容易看到

GET 能直接在歷史記錄中看到，能被緩存，而 POST 不可緩存，有歷史記錄就會(huì)有很多安全隱患

GET 冪等的，多次點(diǎn)擊是不會(huì)產(chǎn)生副作用的，而post是非冪等的

九，cookie，seeion，token對(duì)比：

cookie 舉例：服務(wù)器看你的身份證，然后給你一個(gè)編號(hào)，以后進(jìn)行任何操作，都出示編號(hào)后服務(wù)員去看服務(wù)器上的身份證庫(kù)查你是誰。

token 舉例：我發(fā)給你一張加密的身份證，以后你只要出示這張卡片，我就知道你一定是自己人。

seeion舉例: ?我發(fā)給你一張身份證，但只是一張寫著身份證號(hào)碼的紙片。你每次來辦事，我去后臺(tái)查一下你的 id 是不是有效。

說下區(qū)別特點(diǎn)：

cookie與session的其他不同之處:

1、存儲(chǔ)位置不同

cookie的數(shù)據(jù)信息存放在客戶端瀏覽器上。

session的數(shù)據(jù)信息存放在服務(wù)器上。

2、存儲(chǔ)容量不同

單個(gè)cookie保存的數(shù)據(jù)<=4KB，一個(gè)站點(diǎn)最多保存20個(gè)Cookie。

對(duì)于session來說并沒有上限，但出于對(duì)服務(wù)器端的性能考慮，session內(nèi)不要存放過多的東西，并且設(shè)置session刪除機(jī)制。

3、存儲(chǔ)方式不同

cookie中只能保管ASCII字符串，并需要通過編碼方式存儲(chǔ)為Unicode字符或者二進(jìn)制數(shù)據(jù)。

session中能夠存儲(chǔ)任何類型的數(shù)據(jù)，包括且不限于string，integer，list，map等。

4、隱私策略不同

cookie對(duì)客戶端是可見的，別有用心的人可以分析存放在本地的cookie并進(jìn)行cookie欺騙，所以它是不安全的。

session存儲(chǔ)在服務(wù)器上，對(duì)客戶端是透明的，不存在敏感信息泄漏的風(fēng)險(xiǎn)。

5、有效期上不同

開發(fā)可以通過設(shè)置cookie的屬性，達(dá)到使cookie長(zhǎng)期有效的效果。

session依賴于名為JSESSIONID的cookie，而cookie JSESSIONID的過期時(shí)間默認(rèn)為-1，只需關(guān)閉窗口該session就會(huì)失效，因而session不能達(dá)到長(zhǎng)期有效的效果。

6、服務(wù)器壓力不同

cookie保管在客戶端，不占用服務(wù)器資源。對(duì)于并發(fā)用戶十分多的網(wǎng)站，cookie是很好的選擇。

session是保管在服務(wù)器端的，每個(gè)用戶都會(huì)產(chǎn)生一個(gè)session。假如并發(fā)訪問的用戶十分多，會(huì)產(chǎn)生十分多的session，耗費(fèi)大量的內(nèi)存。

7、瀏覽器支持不同

假如客戶端瀏覽器不支持cookie：

cookie是需要客戶端瀏覽器支持的，假如客戶端禁用了cookie，或者不支持cookie，則會(huì)話跟蹤會(huì)失效。關(guān)于WAP上的應(yīng)用，常規(guī)的cookie就派不上用場(chǎng)了。

運(yùn)用session需要使用URL地址重寫的方式。一切用到session程序的URL都要進(jìn)行URL地址重寫，否則session會(huì)話跟蹤還會(huì)失效。

假如客戶端支持cookie：

cookie既能夠設(shè)為本瀏覽器窗口以及子窗口內(nèi)有效，也能夠設(shè)為一切窗口內(nèi)有效。

session只能在本窗口以及子窗口內(nèi)有效。

8、跨域支持上不同

cookie支持跨域名訪問。

session不支持跨域名訪問。

cookie和token的區(qū)別

cookie：登陸后，后端生成一個(gè)sessionid放在cookie中返回給客戶端，并且服務(wù)端一直記錄著這個(gè)sessionid，客戶端以后每次請(qǐng)求都會(huì)帶上這個(gè)sessionid，服務(wù)端通過這個(gè)sessionid來驗(yàn)證身份之類的操作。所以別人拿到了cookie等于拿到了sessionid，就可以完全替代你。

token：登陸后，后端會(huì)返回一個(gè)token給客戶端，客戶端將這個(gè)token存儲(chǔ)起來，然后每次客戶端請(qǐng)求都需要開發(fā)者手動(dòng)將token放在header中帶過去，服務(wù)端每次只需要對(duì)這個(gè)token進(jìn)行驗(yàn)證就能使用token中的信息來進(jìn)行下一步操作了。

十，在瀏覽器輸入一個(gè)url，然后進(jìn)行搜索，這個(gè)頁(yè)面展示流程是怎么工作的

第一步 DNS域名解析協(xié)議，把域名地址解析為IP地址

第二步?TCP連接，進(jìn)行三次握手

第三步 客戶端發(fā)送HTTP請(qǐng)求到服務(wù)器端

第四步 服務(wù)器端處理請(qǐng)求，返回HTTP報(bào)文

第五步 瀏覽器接收返回HTTP報(bào)文，進(jìn)行渲染展示

第六步 斷開連接 進(jìn)行四次揮手

十一，上網(wǎng)的時(shí)候非常卡，加載很慢

第一，是不是網(wǎng)速太慢了，帶寬不足，硬件配置太低，內(nèi)存被占滿

第二，網(wǎng)頁(yè)的js腳本太大，阻塞了頁(yè)面的加載

第三，HTTP請(qǐng)求次數(shù)太多，或者網(wǎng)頁(yè)上資源太多，有文檔有視頻

第四，接收數(shù)據(jù)的時(shí)間比較長(zhǎng)，加載某個(gè)資源比較慢

第五，DNS?域名解析協(xié)議解析的速度比較慢