HTTP相關(guān)--知識點
2021-09-30 17:00:59

一、輸入url到網(wǎng)頁顯示出來中間的過程

1. 首先，在瀏覽器地址欄中輸入url
2. 瀏覽器先查看瀏覽器緩存-系統(tǒng)緩存-路由器緩存，如果緩存中有，會直接在屏幕中顯示頁面內(nèi)容。若沒有，則跳到第三步操作。
3. 在發(fā)送http請求前，需要域名解析(DNS解析)(DNS（域名系統(tǒng)，Domain Name System）是互聯(lián)網(wǎng)的一項核心服務(wù)，它作為可以將域名和IP地址相互映射的一個分布式數(shù)據(jù)庫，能夠使人更方便的訪問互聯(lián)網(wǎng)，而不用去記住IP地址。)，解析獲取相應(yīng)的IP地址。
4. 瀏覽器向服務(wù)器發(fā)起tcp連接，與瀏覽器建立tcp三次握手。（TCP即傳輸控制協(xié)議。TCP連接是互聯(lián)網(wǎng)連接協(xié)議集的一種。）
5. 握手成功后，瀏覽器向服務(wù)器發(fā)送http請求，請求數(shù)據(jù)包。
6. 服務(wù)器處理收到的請求，將數(shù)據(jù)返回至瀏覽器
7. 瀏覽器收到HTTP響應(yīng)
8. 讀取頁面內(nèi)容，瀏覽器渲染，解析html源碼
9. 生成Dom樹、解析css樣式、js交互
10. 客戶端和服務(wù)器交互
11. ajax查詢

二、HTTP和HTTPS的基本概念

　　HTTP：是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，是一個客戶端和服務(wù)器端請求和應(yīng)答的標準（TCP），用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議，它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。

　　HTTPS：是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細內(nèi)容就需要SSL。

　　HTTPS協(xié)議的主要作用可以分為兩種：一種是建立一個信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩?；另一種就是確認網(wǎng)站的真實性。

三、HTTP與HTTPS有什么區(qū)別？

　　HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的，因此使用HTTP協(xié)議傳輸隱私信息非常不安全，為了保證這些隱私數(shù)據(jù)能加密傳輸，于是網(wǎng)景公司設(shè)計了SSL（Secure Sockets Layer）協(xié)議用于對HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進行加密，從而就誕生了HTTPS。簡單來說，HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全。

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

1. https協(xié)議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2. http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。
3. http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4. http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

四、一個HTTP請求報文是什么樣的？（GET舉例）

? ? ?http的請求報文和響應(yīng)報文的格式基本一樣，主要分為三部分：

1. 起始行（start line）: 描述請求或響應(yīng)的狀態(tài)
2. 頭部字段（header）: 以 key：value 的形式展示
3. 數(shù)據(jù)實體（entity/ body） ：實際要傳輸?shù)臄?shù)據(jù)，可以是文本，也可以是圖片、文件、視頻等二進制數(shù)據(jù)

五、常見的請求 Header 頭

? ? ? ? Request header：Host: www.test.com/ //請求的目標域名和端口號
? ? ? ??Origin: http://localhost:8081/ //請求的來源域名和端口號 （跨域請求時，瀏覽器會自動帶上這個頭信息）
? ? ? ??Referer: https:/localhost:8081/link?query=xxxxx //請求資源的完整
? ? ? ??URI User-Agent //瀏覽器信息
? ? ? ??Cookie: //當(dāng)前域名下的
? ? ? ??Cookie Accept: text/html,image/apng //代表客戶端希望接受的數(shù)據(jù)類型是html或者是png圖片類型
? ? ? ??Accept-Encoding: gzip, deflate //代表客戶端能支持gzip和deflate格式的壓縮 Accept-Language: zh-CN,zh;q=0.9 //代表客戶端可以支持語言zh-CN或者zh(值得一提的是q(0~1)是優(yōu)先級權(quán)重的意思，不寫默認為1，這里zh-CN是1，zh是0.9)
? ? ? ??Connection: keep-alive //告訴服務(wù)器，客戶端需要的tcp連接是一個長連接
? ? ? ??If-None-Match //如果內(nèi)容未改變返回304代碼，對應(yīng)Etag
? ? ? ??If-Modified-Since //對應(yīng)last-midified，未被修改則返回304代碼
? ? ? ??Response header：
? ? ? ??Date: //服務(wù)端發(fā)送資源時的服務(wù)器時間
? ? ? ??Expires: //緩存過期時間
? ? ? ??Cache-Control: no-cache // 緩存方式
? ? ? ??Etag // 文件內(nèi)容
? ? ? ??hash Last-Modified //最近一次文件修改時間
? ? ? ??Content-Type: text/html; charset=utf-8 //編碼格式
? ? ? ??Content-Encoding: gzip //采用gzip對資源進行解碼
? ? ? ??Connection: keep-alive //tcp是長連接
? ? ? ??Set-Cookie //設(shè)置Http Cookie

六、tcp三次握手，四次揮手

? ? ? ? 第一次握手：建立連接時，客戶端發(fā)送syn包（syn=j）到服務(wù)器，并進入SYN_SENT狀態(tài)，等待服務(wù)器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。
? ? ? ? 第二次握手：服務(wù)器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發(fā)送一個SYN包（syn=k），即SYN+ACK包，此時服務(wù)器進入SYN_RECV狀態(tài)；
? ? ? ? 第三次握手：客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認包ACK(ack=k+1），此包發(fā)送完畢，客戶端和服務(wù)器進入ESTABLISHED（TCP連接成功）狀態(tài)，完成三次握手。

? ? ? ?為什么連接的時候是三次握手，關(guān)閉的時候卻是四次握手？

? ? ? ?因為當(dāng)Server端收到Client端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。其中ACK報文是用來應(yīng)答的，SYN報文是用來同步的。但是關(guān)閉連接時，當(dāng)Server端收到FIN報文時，很可能并不會立即關(guān)閉SOCKET，所以只能先回復(fù)一個ACK報文，告訴Client端，"你發(fā)的FIN報文我收到了"。只有等到我Server端所有的報文都發(fā)送完了，我才能發(fā)送FIN報文，因此不能一起發(fā)送。故需要四步握手。

? ? ? ?為什么不能用兩次握手進行連接？

? ? ? ?3次握手完成兩個重要的功能，既要雙方做好發(fā)送數(shù)據(jù)的準備工作(雙方都知道彼此已準備好)，也要允許雙方就初始序列號進行協(xié)商，這個序列號在握手過程中被發(fā)送和確認。
如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？
TCP還設(shè)有一個?；钣嫊r器，顯然，客戶端如果出現(xiàn)故障，服務(wù)器不能一直等下去，白白浪費資源。服務(wù)器每收到一次客戶端的請求后都會重新復(fù)位這個計時器，時間通常是設(shè)置為2小時，若兩小時還沒有收到客戶端的任何數(shù)據(jù)，服務(wù)器就會發(fā)送一個探測報文段，以后每隔75秒鐘發(fā)送一次。若一連發(fā)送10個探測報文仍然沒反應(yīng)，服務(wù)器就認為客戶端出了故障，接著就關(guān)閉連接。

七、Get和post的區(qū)別

? ? ? ? GET在瀏覽器回退時是無害的，而POST會再次提交請求。
? ? ? ??GET產(chǎn)生的URL地址可以被Bookmark，而POST不可以。
? ? ? ??GET請求會被瀏覽器主動cache，而POST不會，除非手動設(shè)置。
? ? ? ??GET請求只能進行url編碼，而POST支持多種編碼方式。
? ? ? ??GET請求參數(shù)會被完整保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會被保留。
? ? ? ??GET請求在URL中傳送的參數(shù)是有長度限制的，而POST么有。
? ? ? ??對參數(shù)的數(shù)據(jù)類型，GET只接受ASCII字符，而POST沒有限制。
? ? ? ??GET比POST更不安全，因為參數(shù)直接暴露在URL上，所以不能用來傳遞敏感信息。
? ? ? ??GET參數(shù)通過URL傳遞，POST放在Request body中。

? ? ? ??GET和POST還有一個重大區(qū)別，簡單的說：
? ? ? ??GET產(chǎn)生一個TCP數(shù)據(jù)包；POST產(chǎn)生兩個TCP數(shù)據(jù)包。
? ? ? ??長的說：
? ? ? ??對于GET方式的請求，瀏覽器會把http header和data一并發(fā)送出去，服務(wù)器響應(yīng)200（返回數(shù)據(jù)）；
? ? ? ??而對于POST，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200 ok（返回數(shù)據(jù)）。
? ? ? ??應(yīng)用的區(qū)別：
? ? ? ??如下情況使用GET方法：客戶端與服務(wù)端的交互像是一個提問(如查詢操作、搜索操作、讀操作)
? ? ? ??如下情況使用POST方法：
? ? ? ??1.交互是一個命令或訂單(order)，比提問包含更多信息
? ? ? ??2.交互改變了服務(wù)器端的資源并被用戶察覺，例如訂閱某項服務(wù)
? ? ? ??3.用戶需要對交互產(chǎn)生的結(jié)果負責(zé)

八、Cookie和Session的區(qū)別

? ? ? ? 1.存儲位置不同
? ? ? ? ? ?cookie的數(shù)據(jù)信息存放在客戶端瀏覽器上。
? ? ? ? ? ?session的數(shù)據(jù)信息存放在服務(wù)器上。
? ? ? ??2.存儲容量不同
? ? ? ? ? ?單個cookie保存的數(shù)據(jù)<=4KB，一個站點最多保存20個Cookie。
? ? ? ? ? ?對于session來說并沒有上限，但出于對服務(wù)器端的性能考慮，session內(nèi)不要存放過多的東西，并且設(shè)置session刪除機制。
? ? ? ??3.存儲方式不同
? ? ? ? ? ?cookie中只能保管ASCII字符串，并需要通過編碼方式存儲為Unicode字符或者二進制數(shù)據(jù)。
? ? ? ? ? ?session中能夠存儲任何類型的數(shù)據(jù)，包括且不限于string，integer，list，map等。
? ? ? ??4.隱私策略不同
? ? ? ? ? ?cookie對客戶端是可見的，別有用心的人可以分析存放在本地的cookie并進行cookie欺騙，所以它是不安全的。
? ? ? ? ? ?session存儲在服務(wù)器上，對客戶端是透明對，不存在敏感信息泄漏的風(fēng)險。
? ? ? ??5.有效期上不同
? ? ? ? ? ?開發(fā)可以通過設(shè)置cookie的屬性，達到使cookie長期有效的效果。
? ? ? ? ? ?session依賴于名為JSESSIONID的cookie，而cookie JSESSIONID的過期時間默認為-1，只需關(guān)閉窗口該session就會失效，因而session不能達到長期有效的效果。
? ? ? ??6.服務(wù)器壓力不同
? ? ? ? ? ?cookie保管在客戶端，不占用服務(wù)器資源。對于并發(fā)用戶十分多的網(wǎng)站，cookie是很好的選擇。
? ? ? ? ? ?session是保管在服務(wù)器端的，每個用戶都會產(chǎn)生一個session。假如并發(fā)訪問的用戶十分多，會產(chǎn)生十分多的session，耗費大量的內(nèi)存。
? ? ? ??7.瀏覽器支持不同
? ? ? ? ? ?假如客戶端瀏覽器不支持cookie：
? ? ? ? ? ?cookie是需要客戶端瀏覽器支持的，假如客戶端禁用了cookie，或者不支持cookie，則會話跟蹤會失效。關(guān)于WAP上的應(yīng)用，常規(guī)的cookie就派不上用場了。
? ? ? ? ? ?運用session需要使用URL地址重寫的方式。一切用到session程序的URL都要進行URL地址重寫，否則session會話跟蹤還會失效。
? ? ? ? ? ?假如客戶端支持cookie：
? ? ? ? ? ?cookie既能夠設(shè)為本瀏覽器窗口以及子窗口內(nèi)有效，也能夠設(shè)為一切窗口內(nèi)有效。
? ? ? ? ? ?session只能在本窗口以及子窗口內(nèi)有效。
? ? ? ??8.跨域支持上不同
? ? ? ? ? ?cookie支持跨域名訪問。
? ? ? ? ? ?session不支持跨域名訪問。

九、Session的儲存

? ? ? ??1.files
? ? ? ? ? ?文件存儲，默認存儲方式
? ? ? ? ? ?可通過設(shè)置session.save_path指定session存儲位置，此方式常見，默認即可使用。
? ? ? ? 2.redis
? ? ? ? ? ?redis存儲，需要安裝redis擴展
? ? ? ? ? ?在redis-cli中查看key
? ? ? ? 3.memcached
? ? ? ? ? ?memcached存儲，需要安裝memcached擴展，此擴展再phpinfo中查看名稱為memcache

?