1. OSI與TCP/IP各層的結(jié)構(gòu)與功能狞悲，都有哪些協(xié)議
   1.1 應用層
   1.2 運輸層
   1.3 網(wǎng)絡層
   1.4 數(shù)據(jù)鏈路層
   1.5 物理層
   1.6 總結(jié)
2. TCP三次握手和四次揮手
   2.1 TCP三次握手圖解
   2.2 為什么要三次握手
   2.3 第2次握手傳回了ACK，為什么還要傳回SYN蔗怠？
   2.4 為什么要四次揮手？
3. TCP, UDP協(xié)議的區(qū)別
4. TCP協(xié)議如何保證可靠傳輸
   4.1 ARQ協(xié)議
   4.2 滑動窗口和流量控制
   4.3 擁塞控制
5. 在瀏覽器中輸入url地址 ->> 顯示主頁的過程
6. 狀態(tài)碼
7. 各種協(xié)議與HTTP協(xié)議之間的關(guān)系
8. HTTP長連接,短連接
9. HTTP是不保存狀態(tài)的協(xié)議,如何保存用戶狀態(tài)?
10. Cookie的作用是什么?和Session有什么區(qū)別泵督？
11. HTTP 1.0和HTTP 1.1的主要區(qū)別是什么?
12. URI和URL的區(qū)別是什么?
13. HTTP和HTTPS的區(qū)別?

1.OSI與TCP/IP各層的結(jié)構(gòu)與功能懂从，都有哪些協(xié)議

網(wǎng)絡分層協(xié)議

1.1 應用層

應用層(application-layer）的任務是通過應用進程間的交互來完成特定網(wǎng)絡應用。應用層協(xié)議定義的是應用進程（進程：主機中正在運行的程序）間的通信和交互的規(guī)則兜喻。對于不同的網(wǎng)絡應用需要不同的應用層協(xié)議。在互聯(lián)網(wǎng)中應用層協(xié)議很多喧枷，如域名系統(tǒng)DNS虹统，支持萬維網(wǎng)應用的 HTTP協(xié)議，支持電子郵件的 SMTP協(xié)議等等隧甚。我們把應用層交互的數(shù)據(jù)單元稱為報文车荔。

域名系統(tǒng)
域名系統(tǒng)(Domain Name System縮寫 DNS，Domain Name被譯為域名)是因特網(wǎng)的一項核心服務戚扳，它作為可以將域名和IP地址相互映射的一個分布式數(shù)據(jù)庫忧便，能夠使人更方便的訪問互聯(lián)網(wǎng)，而不用去記住能夠被機器直接讀取的IP數(shù)串。

HTTP協(xié)議
超文本傳輸協(xié)議（HTTP珠增，HyperText Transfer Protocol)是互聯(lián)網(wǎng)上應用最為廣泛的一種網(wǎng)絡協(xié)議超歌。所有的 WWW（萬維網(wǎng)） 文件都必須遵守這個標準。設計 HTTP 最初的目的是為了提供一種發(fā)布和接收 HTML 頁面的方法蒂教。

1.2 運輸層

接收上層的數(shù)據(jù)巍举，必要時分割數(shù)據(jù)，把數(shù)據(jù)交給網(wǎng)絡層凝垛，保證數(shù)據(jù)到對端懊悯。
運輸層(transport layer)的主要任務就是負責向兩臺主機進程之間的通信提供通用的數(shù)據(jù)傳輸服務。應用進程利用該服務傳送應用層報文梦皮√糠郑“通用的”是指并不針對某一個特定的網(wǎng)絡應用，而是多種應用可以使用同一個運輸層服務剑肯。由于一臺主機可同時運行多個線程捧毛，因此運輸層有復用和分用的功能。所謂復用就是指多個應用層進程可同時使用下面運輸層的服務让网，分用和復用相反呀忧，是運輸層把收到的信息分別交付上面應用層中的相應進程。

運輸層主要使用以下兩種協(xié)議:

1. 傳輸控制協(xié)議 TCP（Transmission Control Protocol）-- 提供面向連接的寂祥，可靠的數(shù)據(jù)傳輸服務荐虐。(建立會話)
2. 用戶數(shù)據(jù)協(xié)議 UDP（User Datagram Protocol）-- 提供無連接的七兜，盡最大努力的數(shù)據(jù)傳輸服務（不保證數(shù)據(jù)傳輸?shù)目煽啃裕?/li>

1.3 網(wǎng)絡層

在 計算機網(wǎng)絡中進行通信的兩個計算機之間可能會經(jīng)過很多個數(shù)據(jù)鏈路丸凭，也可能還要經(jīng)過很多通信子網(wǎng)。網(wǎng)絡層的任務就是選擇合適的網(wǎng)間路由和交換結(jié)點腕铸， 確保數(shù)據(jù)及時傳送惜犀。 在發(fā)送數(shù)據(jù)時，網(wǎng)絡層把運輸層產(chǎn)生的報文段或用戶數(shù)據(jù)報封裝成分組和包進行傳送狠裹。在 TCP/IP 體系結(jié)構(gòu)中虽界，由于網(wǎng)絡層使用 IP 協(xié)議，因此分組也叫 IP 數(shù)據(jù)報 涛菠，簡稱 數(shù)據(jù)報莉御。

1.4 數(shù)據(jù)鏈路層

簡單點理解就是物理尋址，把對應的IP地址轉(zhuǎn)換成MAC地址俗冻。

數(shù)據(jù)鏈路層(data link layer)通常簡稱為鏈路層礁叔。兩臺主機之間的數(shù)據(jù)傳輸，總是在一段一段的鏈路上傳送的迄薄，這就需要使用專門的鏈路層的協(xié)議琅关。 在兩個相鄰節(jié)點之間傳送數(shù)據(jù)時，數(shù)據(jù)鏈路層將網(wǎng)絡層交下來的 IP 數(shù)據(jù)報組裝成幀讥蔽，在兩個相鄰節(jié)點間的鏈路上傳送幀涣易。每一幀包括數(shù)據(jù)和必要的控制信息（如同步信息画机，地址信息，差錯控制等）新症。

在接收數(shù)據(jù)時步氏，控制信息使接收端能夠知道一個幀從哪個比特開始和到哪個比特結(jié)束。這樣徒爹，數(shù)據(jù)鏈路層在收到一個幀后戳护，就可從中提出數(shù)據(jù)部分，上交給網(wǎng)絡層瀑焦。 控制信息還使接收端能夠檢測到所收到的幀中有誤差錯腌且。如果發(fā)現(xiàn)差錯，數(shù)據(jù)鏈路層就簡單地丟棄這個出了差錯的幀榛瓮，以避免繼續(xù)在網(wǎng)絡中傳送下去白白浪費網(wǎng)絡資源铺董。如果需要改正數(shù)據(jù)在鏈路層傳輸時出現(xiàn)差錯（這就是說，數(shù)據(jù)鏈路層不僅要檢錯禀晓，而且還要糾錯）精续，那么就要采用可靠性傳輸協(xié)議來糾正出現(xiàn)的差錯。這種方法會使鏈路層的協(xié)議復雜些粹懒。

1.5 物理層

在物理層上所傳送的數(shù)據(jù)單位是比特重付。 物理層(physical layer)的作用是實現(xiàn)相鄰計算機節(jié)點之間比特流的透明傳送，盡可能屏蔽掉具體傳輸介質(zhì)和物理設備的差異凫乖。 使其上面的數(shù)據(jù)鏈路層不必考慮網(wǎng)絡的具體傳輸介質(zhì)是什么确垫。“透明傳送比特流”表示經(jīng)實際電路傳送后的比特流沒有發(fā)生變化帽芽，對傳送的比特流來說删掀，這個電路好像是看不見的。

1.6 總結(jié)

網(wǎng)絡七層協(xié)議.png

2. TCP三次握手和四次揮手

三次握手: 保證可以準確無誤的把數(shù)據(jù)送達目標處导街。

2.1 TCP三次握手圖解

通過3次握手確定了對方能正確接收和發(fā)送消息披泪。

三次握手過程

• 客戶端–發(fā)送帶有 SYN 標志的數(shù)據(jù)包–一次握手–服務端
• 服務端–發(fā)送帶有 SYN/ACK 標志的數(shù)據(jù)包–二次握手–客戶端
• 客戶端–發(fā)送帶有帶有 ACK 標志的數(shù)據(jù)包–三次握手–服務端

2.2 為什么要三次握手

三次握手的目的是建立可靠的通信信道，說到通訊搬瑰，簡單來說就是數(shù)據(jù)的發(fā)送與接收款票，而三次握手最主要的目的就是雙方確認自己與對方的發(fā)送與接收是正常的。

第一次握手：Client 什么都不能確認泽论；Server 確認了對方發(fā)送正常艾少，自己接收正常

第二次握手：Client 確認了：自己發(fā)送、接收正常佩厚，對方發(fā)送姆钉、接收正常；Server 確認了：對方發(fā)送正常，自己接收正常

第三次握手：Client 確認了：自己發(fā)送潮瓶、接收正常陶冷，對方發(fā)送、接收正常毯辅；Server 確認了：自己發(fā)送埂伦、接收正常，對方發(fā)送思恐、接收正常

所以三次握手就能確認雙發(fā)收發(fā)功能都正常沾谜，缺一不可。

2.3 第2次握手傳回了ACK胀莹，為什么還要傳回SYN基跑？

接收端傳回發(fā)送端所發(fā)送的ACK是為了告訴客戶端，我接收到的信息確實就是你所發(fā)送的信號了描焰，這表明從客戶端到服務端的通信是正常的媳否。而回傳SYN則是為了建立并確認從服務端到客戶端的通信。

2.4 為什么要四次揮手荆秦？

四次揮手

斷開一個 TCP 連接則需要“四次揮手”：

• 客戶端 - 發(fā)送一個 FIN篱竭，用來關(guān)閉客戶端到服務器的數(shù)據(jù)傳送
• 服務器 - 收到這個 FIN，它發(fā)回一 個 ACK步绸，確認序號為收到的序號加1 掺逼。和 SYN 一樣，一個 FIN 將占用一個序號
• 服務器 - 關(guān)閉與客戶端的連接瓤介，發(fā)送一個FIN給客戶端
• 客戶端 - 發(fā)回 ACK 報文確認吕喘，并將確認序號設置為收到序號加1

任何一方都可以在數(shù)據(jù)傳送結(jié)束后發(fā)出連接釋放的通知，待對方確認后進入半關(guān)閉狀態(tài)惑朦。當另一方也沒有數(shù)據(jù)再發(fā)送的時候兽泄，則發(fā)出連接釋放通知漓概，對方確認后就完全關(guān)閉了TCP連接漾月。（保證數(shù)據(jù)完全發(fā)完才關(guān)閉連接）

舉個例子：A 和 B 打電話，通話即將結(jié)束后胃珍，A 說“我沒啥要說的了”梁肿，B回答“我知道了”，但是 B 可能還會有要說的話觅彰，A 不能要求 B 跟著自己的節(jié)奏結(jié)束通話吩蔑，于是 B 可能又巴拉巴拉說了一通，最后 B 說“我說完了”填抬，A 回答“知道了”烛芬，這樣通話才算結(jié)束。

3. TCP, UDP協(xié)議的區(qū)別

TCP與UDP的區(qū)別

UDP 在傳送數(shù)據(jù)之前不需要先建立連接，遠地主機在收到 UDP 報文后赘娄，不需要給出任何確認仆潮。雖然 UDP 不提供可靠交付，但在某些情況下 UDP 確是一種最有效的工作方式（一般用于即時通信）遣臼，比如： QQ 語音性置、 QQ 視頻 、直播等等

TCP 提供面向連接的服務揍堰。在傳送數(shù)據(jù)之前必須先建立連接鹏浅，數(shù)據(jù)傳送結(jié)束后要釋放連接。 TCP 不提供廣播或多播服務屏歹。由于 TCP 要提供可靠的隐砸，面向連接的傳輸服務（TCP的可靠體現(xiàn)在TCP在傳遞數(shù)據(jù)之前，會有三次握手來建立連接蝙眶，而且在數(shù)據(jù)傳遞時凰萨，有確認、窗口械馆、重傳胖眷、擁塞控制機制，在數(shù)據(jù)傳完后霹崎，還會斷開連接用來節(jié)約系統(tǒng)資源）珊搀，這一難以避免增加了許多開銷，如確認尾菇，流量控制境析，計時器以及連接管理等。這不僅使協(xié)議數(shù)據(jù)單元的首部增大很多派诬，還要占用許多處理機資源劳淆。TCP 一般用于文件傳輸、發(fā)送和接收郵件默赂、遠程登錄等場景沛鸵。

4. TCP協(xié)議如何保證可靠傳輸

1. 應用數(shù)據(jù)被分割成TCP認為最合適發(fā)送的數(shù)據(jù)塊
2. 給數(shù)據(jù)包編號，接收方對數(shù)據(jù)包排序缆八，傳送有序數(shù)據(jù)給應用層
3. 校驗和： TCP 將保持它首部和數(shù)據(jù)的檢驗和曲掰。這是一個端到端的檢驗和，目的是檢測數(shù)據(jù)在傳輸過程中的任何變化奈辰。如果收到段的檢驗和有差錯栏妖，TCP 將丟棄這個報文段和不確認收到此報文段。
4. TCP 的接收端會丟棄重復的數(shù)據(jù)奖恰。
5. ARQ協(xié)議： 也是為了實現(xiàn)可靠傳輸?shù)牡踔海幕驹砭褪敲堪l(fā)完一個分組就停止發(fā)送宛裕，等待對方確認。在收到確認后再發(fā)下一個分組论泛。
6. 超時重傳： 當 TCP 發(fā)出一個段后续滋，它啟動一個定時器，等待目的端確認收到這個報文段孵奶。如果不能及時收到一個確認疲酌，將重發(fā)這個報文段。
7. 流量控制： TCP 連接的每一方都有固定大小的緩沖空間了袁，TCP的接收端只允許發(fā)送端發(fā)送接收端緩沖區(qū)能接納的數(shù)據(jù)朗恳。當接收方來不及處理發(fā)送方的數(shù)據(jù)，能提示發(fā)送方降低發(fā)送的速率载绿，防止包丟失粥诫。TCP 使用的流量控制協(xié)議是可變大小的滑動窗口協(xié)議。 （TCP 利用滑動窗口實現(xiàn)流量控制）
8. 擁塞控制： 當網(wǎng)絡擁塞時崭庸，減少數(shù)據(jù)的發(fā)送怀浆。

4.1 ARQ協(xié)議

自動重傳請求（Automatic Repeat-reQuest，ARQ）是OSI模型中數(shù)據(jù)鏈路層和傳輸層的錯誤糾正協(xié)議之一怕享。它通過使用確認和超時這兩個機制执赡，在不可靠服務的基礎上實現(xiàn)可靠的信息傳輸。如果發(fā)送方在發(fā)送后一段時間之內(nèi)沒有收到確認幀函筋，它通常會重新發(fā)送沙合。ARQ包括停止等待ARQ協(xié)議和連續(xù)ARQ協(xié)議。

a). 停止等待ARQ協(xié)議

• 停止等待協(xié)議是為了實現(xiàn)可靠傳輸?shù)牡剩幕驹砭褪敲堪l(fā)完一個分組就停止發(fā)送首懈，等待對方確認（回復ACK）。如果過了一段時間（超時時間后）谨敛，還是沒有收到 ACK 確認究履，說明沒有發(fā)送成功，需要重新發(fā)送脸狸，直到收到確認后再發(fā)下一個分組最仑；
• 在停止等待協(xié)議中，若接收方收到重復分組肥惭，就丟棄該分組盯仪，但同時還要發(fā)送確認；

優(yōu)點： 簡單
缺點： 信道利用率低蜜葱，等待時間長

傳送過程中:
1). 無差錯情況:
發(fā)送方發(fā)送分組,接收方在規(guī)定時間內(nèi)收到,并且回復確認.發(fā)送方再次發(fā)送。

2). 出現(xiàn)差錯情況(超時重傳):
停止等待協(xié)議中超時重傳是指只要超過一段時間仍然沒有收到確認耀石，就重傳前面發(fā)送過的分組（認為剛才發(fā)送過的分組丟失了）牵囤。因此每發(fā)送完一個分組需要設置一個超時計時器爸黄，其重傳時間應比數(shù)據(jù)在分組傳輸?shù)钠骄禃r間更長一些。這種自動重傳方式常稱為 自動重傳請求 ARQ 揭鳞。另外在停止等待協(xié)議中若收到重復分組炕贵，就丟棄該分組，但同時還要發(fā)送確認野崇。

3). 確認丟失和確認遲到

• 確認丟失 ：確認消息在傳輸過程丟失称开。當A發(fā)送M1消息，B收到后乓梨，B向A發(fā)送了一個M1確認消息鳖轰，但卻在傳輸過程中丟失。而A并不知道扶镀，在超時計時過后蕴侣，A重傳M1消息，B再次收到該消息后采取以下兩點措施：1. 丟棄這個重復的M1消息臭觉，不向上層交付昆雀。 2. 向A發(fā)送確認消息。（不會認為已經(jīng)發(fā)送過了蝠筑，就不再發(fā)送狞膘。A能重傳，就證明B的確認消息丟失）什乙。

• 確認遲到 ：確認消息在傳輸過程中遲到客冈。A發(fā)送M1消息，B收到并發(fā)送確認稳强。在超時時間內(nèi)沒有收到確認消息场仲，A重傳M1消息，B仍然收到并繼續(xù)發(fā)送確認消息（B收到了2份M1）退疫。此時A收到了B第二次發(fā)送的確認消息渠缕。接著發(fā)送其他數(shù)據(jù)。過了一會褒繁，A收到了B第一次發(fā)送的對M1的確認消息（A也收到了2份確認消息）亦鳞。處理如下：1. A收到重復的確認后，直接丟棄棒坏。2. B收到重復的M1后燕差，也直接丟棄重復的M1。

b). 連續(xù)ARQ協(xié)議

連續(xù) ARQ 協(xié)議可提高信道利用率坝冕。發(fā)送方維持一個發(fā)送窗口徒探，凡位于發(fā)送窗口內(nèi)的分組可以連續(xù)發(fā)送出去，而不需要等待對方確認喂窟。接收方一般采用累計確認测暗，對按序到達的最后一個分組發(fā)送確認央串，表明到這個分組為止的所有分組都已經(jīng)正確收到了。

優(yōu)點： 信道利用率高碗啄，容易實現(xiàn)质和，即使確認丟失，也不必重傳稚字。

缺點： 不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息饲宿。 比如：發(fā)送方發(fā)送了 5條 消息，中間第三條丟失（3號）胆描，這時接收方只能對前兩個發(fā)送確認瘫想。發(fā)送方無法知道后三個分組的下落，而只好把后三個全部重傳一次袄友。這也叫 Go-Back-N（回退 N）殿托，表示需要退回來重傳已經(jīng)發(fā)送過的 N 個消息。

4.2 滑動窗口和流量控制

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

4.3 擁塞控制

在某段時間馒吴，若對網(wǎng)絡中某一資源的需求超過了該資源所能提供的可用部分，網(wǎng)絡的性能就要變壞瑟曲。這種情況就叫擁塞饮戳。擁塞控制就是為了防止過多的數(shù)據(jù)注入到網(wǎng)絡中，這樣就可以使網(wǎng)絡中的路由器或鏈路不致過載洞拨。擁塞控制所要做的都有一個前提扯罐，就是網(wǎng)絡能夠承受現(xiàn)有的網(wǎng)絡負荷。擁塞控制是一個全局性的過程烦衣，涉及到所有的主機歹河，所有的路由器，以及與降低網(wǎng)絡傳輸性能有關(guān)的所有因素花吟。相反秸歧，流量控制往往是點對點通信量的控制，是個端到端的問題衅澈。流量控制所要做到的就是抑制發(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)丟失時，它則不能很有效地工作酸茴。

5. 在瀏覽器中輸入url地址 ->> 顯示主頁的過程

url地址顯示主頁的過程

總體分為以下幾個過程:

1. DNS解析
2. TCP連接
3. 發(fā)送HTTP請求
4. 服務器處理請求并返回HTTP報文
5. 瀏覽器解析渲染頁面
6. 連接結(jié)束

6. 狀態(tài)碼

狀態(tài)碼

7. 各種協(xié)議與HTTP協(xié)議之間的關(guān)系

各種協(xié)議和HTTP協(xié)議之間的關(guān)系

8. 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連接不會關(guān)閉畏陕，客戶端再次訪問這個服務器時配乓，會繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會永久保持連接惠毁，它有一個保持時間犹芹，可以在不同的服務器軟件（如Apache）中設定這個時間。實現(xiàn)長連接需要客戶端和服務端都支持長連接鞠绰。

HTTP協(xié)議的長連接和短連接腰埂，實質(zhì)上是TCP協(xié)議的長連接和短連接。

9. HTTP是不保存狀態(tài)的協(xié)議,如何保存用戶狀態(tài)?

HTTP 是一種不保存狀態(tài)蜈膨，即無狀態(tài)（stateless）協(xié)議屿笼。也就是說 HTTP 協(xié)議自身不對請求和響應之間的通信狀態(tài)進行保存。Session 機制的存在就是為了解決這個問題翁巍，Session 的主要作用就是通過服務端記錄用戶的狀態(tài)驴一。典型的場景是購物車，當你要添加商品到購物車的時候灶壶，系統(tǒng)不知道是哪個用戶操作的肝断，因為 HTTP 協(xié)議是無狀態(tài)的。服務端給特定的用戶創(chuàng)建特定的 Session 之后就可以標識這個用戶并且跟蹤這個用戶了（一般情況下，服務器會在一定時間內(nèi)保存這個 Session胸懈，過了時間限制担扑，就會銷毀這個Session）。

在服務端保存 Session 的方法很多趣钱，最常用的就是內(nèi)存和數(shù)據(jù)庫(比如是使用內(nèi)存數(shù)據(jù)庫redis保存)涌献。

Session的追蹤方式： 我們都是通過在 Cookie 中附加一個 Session ID 來方式來跟蹤。Cookie 被禁用怎么辦? 最常用的就是利用 URL 重寫把 Session ID 直接附加在URL路徑的后面羔挡。

10. Cookie的作用是什么?和Session有什么區(qū)別洁奈？

Cookie 和 Session都是用來跟蹤瀏覽器用戶身份的會話方式间唉，但是兩者的應用場景不太一樣绞灼。

Cookie 一般用來保存用戶信息 比如①我們在 Cookie 中保存已經(jīng)登錄過得用戶信息，下次訪問網(wǎng)站的時候頁面可以自動幫你登錄的一些基本信息給填了呈野；②一般的網(wǎng)站都會有保持登錄也就是說下次你再訪問網(wǎng)站的時候就不需要重新登錄了低矮，這是因為用戶登錄的時候我們可以存放了一個 Token 在 Cookie 中，下次登錄的時候只需要根據(jù) Token 值來查找用戶即可(為了安全考慮被冒，重新登錄一般要將 Token 重寫)

Session 的主要作用就是通過服務端記錄用戶的狀態(tài)军掂。 典型的場景是購物車，當你要添加商品到購物車的時候昨悼，系統(tǒng)不知道是哪個用戶操作的蝗锥，因為 HTTP 協(xié)議是無狀態(tài)的。服務端給特定的用戶創(chuàng)建特定的 Session 之后就可以標識這個用戶并且跟蹤這個用戶了率触。

Cookie 數(shù)據(jù)保存在客戶端(瀏覽器端)终议，Session 數(shù)據(jù)保存在服務器端。

Cookie 存儲在客戶端中葱蝗，而Session存儲在服務器上穴张，相對來說 Session 安全性更高。如果要在 Cookie 中存儲一些敏感信息两曼，不要直接寫入 Cookie 中皂甘，最好能將 Cookie 信息加密然后使用到的時候再去服務器端解密。

session原理

token和cookie工作原理

11. HTTP 1.0和HTTP 1.1的主要區(qū)別是什么?

1. 長連接 : 在HTTP/1.0中悼凑，默認使用的是短連接偿枕，也就是說每次請求都要重新建立一次連接。HTTP 是基于TCP/IP協(xié)議的,每一次建立或者斷開連接都需要三次握手四次揮手的開銷户辫，如果每次請求都要這樣的話渐夸，開銷會比較大。因此最好能維持一個長連接寸莫，可以用個長連接來發(fā)多個請求捺萌。HTTP 1.1起，默認使用長連接 ,默認開啟Connection： keep-alive。 HTTP/1.1的持續(xù)連接有非流水線方式和流水線方式 桃纯。流水線方式是客戶在收到HTTP的響應報文之前就能接著發(fā)送新的請求報文酷誓。與之相對應的非流水線方式是客戶在收到前一個響應后才能發(fā)送下一個請求。
2. 錯誤狀態(tài)響應碼 :在HTTP1.1中新增了24個錯誤狀態(tài)響應碼态坦，如409（Conflict）表示請求的資源與資源的當前狀態(tài)發(fā)生沖突盐数；410（Gone）表示服務器上的某個資源被永久性的刪除。
3. 緩存處理 :在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標準伞梯，HTTP1.1則引入了更多的緩存控制策略例如Entity tag玫氢，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
4. 帶寬優(yōu)化及網(wǎng)絡連接的使用 :HTTP1.0中谜诫，存在一些浪費帶寬的現(xiàn)象漾峡，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了喻旷，并且不支持斷點續(xù)傳功能生逸，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分且预，即返回碼是206（Partial Content）槽袄，這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接。

12. URI和URL的區(qū)別是什么?

• URI(Uniform Resource Identifier) 是統(tǒng)一資源標志符锋谐，可以唯一標識一個資源遍尺。
• URL(Uniform Resource Location) 是統(tǒng)一資源定位符，可以提供該資源的路徑涮拗。它是一種具體的 URI乾戏，即 URL 可以用來標識一個資源，而且還指明了如何 locate 這個資源多搀。

URL是一種具體的URI歧蕉，它不僅唯一標識資源，而且還提供了定位該資源的信息康铭。

13. HTTP和HTTPS的區(qū)別?

1. 端口 ：HTTP的URL由“http://”起始且默認使用端口80惯退，而HTTPS的URL由“https://”起始且默認使用端口443。
2. 安全性和資源消耗： HTTP協(xié)議運行在TCP之上从藤，所有傳輸?shù)膬?nèi)容都是明文催跪，客戶端和服務器端都無法驗證對方的身份。HTTPS是運行在SSL/TLS之上的HTTP協(xié)議夷野，SSL/TLS 運行在TCP之上懊蒸。所有傳輸?shù)膬?nèi)容都經(jīng)過加密，加密采用對稱加密悯搔，但對稱加密的密鑰用服務器方的證書進行了非對稱加密骑丸。所以說，HTTP 安全性沒有 HTTPS高，但是 HTTPS 比HTTP耗費更多服務器資源通危。