1|前端基礎(chǔ)

1.1|HTTP/HTML/瀏覽器

說一下http和https

參考回答：
https的SSL加密是在傳輸層實(shí)現(xiàn)的。
(1)http和https的基本概念
http:超文本傳輸協(xié)議，是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，是一個客戶端和服
務(wù)器端請求和應(yīng)答的標(biāo)準(zhǔn)（TCP），用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳
輸協(xié)議，它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。
https:是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL
層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。
https協(xié)議的主要作用是：建立一個信息安全通道，來確保數(shù)組的傳輸，確保網(wǎng)站的真實(shí)
性。

(2)http和https的區(qū)別？

http傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的，網(wǎng)景公司設(shè)置了SSL協(xié)議來對http協(xié)議
傳輸?shù)臄?shù)據(jù)進(jìn)行加密處理，簡單來說https協(xié)議是由http和ssl協(xié)議構(gòu)建的可進(jìn)行加密傳
輸和身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議的安全性更高。

主要的區(qū)別如下：

Https協(xié)議需要ca證書，費(fèi)用較高。
http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。
使用不同的鏈接方式，端口也不同，一般而言，http協(xié)議的端口為80，https的端口為
443
http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳
輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

(3)https協(xié)議的工作原理

客戶端在使用HTTPS方式與Web服務(wù)器通信時有以下幾個步驟，如圖所示。
客戶使用httpsurl訪問服務(wù)器，則要求web服務(wù)器建立ssl鏈接。
web服務(wù)器接收到客戶端的請求之后，會將網(wǎng)站的證書（證書中包含了公鑰），返回或
者說傳輸給客戶端。
客戶端和web服務(wù)器端開始協(xié)商SSL鏈接的安全等級，也就是加密等級。
客戶端瀏覽器通過雙方協(xié)商一致的安全等級，建立會話密鑰，然后通過網(wǎng)站的公鑰來加
密會話密鑰，并傳送給網(wǎng)站。
web服務(wù)器通過自己的私鑰解密出會話密鑰。
web服務(wù)器通過會話密鑰加密與客戶端之間的通信。

(4)https協(xié)議的優(yōu)點(diǎn)

使用HTTPS協(xié)議可認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器；

HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比
http協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性。
HTTPS是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻
擊的成本。
谷歌曾在2014年8月份調(diào)整搜索引擎算法，并稱“比起同等HTTP網(wǎng)站，采用HTTPS
加密的網(wǎng)站在搜索結(jié)果中的排名將會更高”。

(5)https協(xié)議的缺點(diǎn)

https握手階段比較費(fèi)時，會使頁面加載時間延長50%，增加10%~20%的耗電。
https緩存不如http高效，會增加數(shù)據(jù)開銷。
SSL證書也需要錢，功能越強(qiáng)大的證書費(fèi)用越高。
SSL證書需要綁定IP，不能再同一個ip上綁定多個域名，ipv4資源支持不了這種消耗。
tcp三次握手，一句話概括
參考回答：
客戶端和服務(wù)端都需要直到各自可收發(fā)，因此需要三次握手。
簡化三次握手：
從圖片可以得到三次握手可以簡化為：C發(fā)起請求連接S確認(rèn)，也發(fā)起連接C確認(rèn)我們
再看看每次握手的作用：第一次握手：S只可以確認(rèn)自己可以接受C發(fā)送的報文段第
二次握手：C可以確認(rèn)S收到了自己發(fā)送的報文段，并且可以確認(rèn)自己可以接受S發(fā)

TCP和UDP的區(qū)別

參考回答：
（1）TCP是面向連接的，udp是無連接的即發(fā)送數(shù)據(jù)前不需要先建立鏈接。
（2）TCP提供可靠的服務(wù)。也就是說，通過TCP連接傳送的數(shù)據(jù)，無差錯，不丟失，
不重復(fù)，且按序到達(dá);UDP盡最大努力交付，即不保證可靠交付。并且因?yàn)閠cp可靠，
面向連接，不會丟失數(shù)據(jù)因此適合大數(shù)據(jù)量的交換。
（3）TCP是面向字節(jié)流，UDP面向報文，并且網(wǎng)絡(luò)出現(xiàn)擁塞不會使得發(fā)送速率降低（因
此會出現(xiàn)丟包，對實(shí)時的應(yīng)用比如IP電話和視頻會議等）。
（4）TCP只能是1對1的，UDP支持1對1,1對多。
（5）TCP的首部較大為20字節(jié)，而UDP只有8字節(jié)。
（6）TCP是面向連接的可靠性傳輸，而UDP是不可靠的。
?

WebSocket的實(shí)現(xiàn)和應(yīng)用

參考回答：

(1)什么是WebSocket?

WebSocket是HTML5中的協(xié)議，支持持久連續(xù)，http協(xié)議不支持持久性連接。Http1.0
和HTTP1.1都不支持持久性的鏈接，HTTP1.1中的keep-alive，將多個http請求合并為
1個
(2)WebSocket是什么樣的協(xié)議，具體有什么優(yōu)點(diǎn)？
HTTP的生命周期通過Request來界定，也就是Request一個Response，那么在Http1.0
協(xié)議中，這次Http請求就結(jié)束了。在Http1.1中進(jìn)行了改進(jìn)，是的有一個connection：
Keep-alive，也就是說，在一個Http連接中，可以發(fā)送多個Request，接收多個Response。
但是必須記住，在Http中一個Request只能對應(yīng)有一個Response，而且這個Response
是被動的，不能主動發(fā)起。
WebSocket是基于Http協(xié)議的，或者說借用了Http協(xié)議來完成一部分握手，在握手階段
與Http是相同的。我們來看一個websocket握手協(xié)議的實(shí)現(xiàn)，基本是2個屬性，upgrade，
connection。
基本請求如下：

Host:server.example.com
Upgrade:websocket
Connection:Upgrade
Sec-WebSocket-Key:x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol:chat,superchat
Sec-WebSocket-Version:13
Origin:http://example.com

多了下面2個屬性：
|Upgrade:webSocket|
|-|-|
|Connection:Upgrade|
|-|-|
告訴服務(wù)器發(fā)送的是websocket
|Sec-WebSocket-Key:x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol:chat,superchat
Sec-WebSocket-Version:13|

HTTP請求的方式，HEAD方式

參考回答：
head：類似于get請求，只不過返回的響應(yīng)中沒有具體的內(nèi)容，用戶獲取報頭
options：允許客戶端查看服務(wù)器的性能，比如說服務(wù)器支持的請求方式等等。