計算機知識基礎(chǔ)補習(xí)

一、強緩存和協(xié)商緩存

強緩存

本地緩存，瀏覽器不會發(fā)請求叔锐，直接從本地緩存中讀取黄痪。
控制強緩存的字段：expires和 cache-control

expires：記錄的是一個絕對時間的字符串紧帕，為過期時間，在這個事件之前桅打，就不需要請求服務(wù)器去拿是嗜。
cache-control：max-age=number，相對時間挺尾，相對時間內(nèi)鹅搪，緩存是有效的。

Cache-Control與Expires可以在服務(wù)端配置同時啟用遭铺，同時啟用的時候Cache-Control優(yōu)先級高

協(xié)商緩存

協(xié)商緩存是需要在服務(wù)端對比資源是否已經(jīng)修改了丽柿，來判斷是否可以使用緩存。若未改動魂挂，返回304狀態(tài)碼甫题。

控制協(xié)商緩存的兩個header字段是：Last-Modify/If-Modified-Since 和 Etag/If-None-Match，這兩個字段是成對使用的涂召。

Last-Modify/If-Modified-Since

瀏覽器第一次請求服務(wù)器的時候坠非，響應(yīng)頭會返回Last-modify字段，記錄資源的最后修改時間果正。
瀏覽器再次請求服務(wù)器炎码，請求頭攜帶If-Modified-Since盟迟，值為緩存之前的時間，根據(jù)資源最后的修改時間判斷是否緩存命中潦闲。若沒有修改队萤，返回304，使用緩存矫钓。若修改要尔，再去服務(wù)器請求資源，返回碼和第一次請求時的返回碼一樣為200新娜。

Etag/If-None-Match

Etag是服務(wù)器根據(jù)資源的內(nèi)容生成的hash字符串赵辕，記錄資源的狀態(tài)，資源只要變換概龄，Etag也會變还惠，然后Etag的值下次會存在請求的If-None-Match字段中。


協(xié)商緩存與強制緩存的區(qū)別在于強制緩存不需要訪問服務(wù)器私杜，返回結(jié)果是200蚕键，協(xié)商緩存需要訪問服務(wù)器，如果命中緩存的話衰粹，返回結(jié)果是304锣光。

Etag相對于last-modified的優(yōu)勢，

  1. 對于某些周期性會修改的文件铝耻，可能內(nèi)容未修改誊爹，但是時間修改了，我們不希望任何這個文件被修改過瓢捉。
  2. 某些文件的修改十分頻繁频丘，1s修改了好多次，If-Modified-since不能精確地匹配最后的修改時間泡态。

緩存機制

瀏覽器發(fā)送請求搂漠，會先根據(jù)響應(yīng)頭的Cache-control和expires判斷是否可用，如果沒過期某弦，就直接從瀏覽器緩存獲取資源桐汤。如果強緩存不可用，就會使用協(xié)商緩存刀崖。
瀏覽器把之前保存的last-modified和etag存在請求頭發(fā)給服務(wù)器惊科，服務(wù)器會自己對照之前的和現(xiàn)在的，若命中亮钦，則返回304空響應(yīng)馆截，否則會返回新的資源和etag以及狀態(tài)碼OK。

二、TCP協(xié)議的三次握手和四次握手

TCP協(xié)議位于傳輸層蜡娶，為了提供可靠的字節(jié)流服務(wù)混卵。為了傳輸方便，把大塊數(shù)據(jù)分割為數(shù)據(jù)包進行管理窖张，且TCP協(xié)議能夠確認數(shù)據(jù)最終是否到達對方幕随，且在傳輸時是有序的。

1. 建立連接：三次握手宿接，使用了TCP的標(biāo)志 SYN（synchronize）和 ACK（acknowledgement）

第一次赘淮，建立連接時，客戶端A發(fā)送SYN包（SYN=j）到服務(wù)器B睦霎，服務(wù)器B收到后知道客戶端希望建立連接梢卸。
第二次，服務(wù)器B收到SYN包副女，確認是A的SYN蛤高，發(fā)ACK=j+1，同時自己也發(fā)SYN=k碑幅。
第三次戴陡，客戶端需要發(fā)送ACK=k+1確認，說知道了你要和我建立連接沟涨，否則恤批，服務(wù)端不知道自己發(fā)的消息客戶端能不能收到。

兩方都知道 自己能發(fā)送消息拷窜，也可以接受消息

第三次握手防止已經(jīng)失效的TCP請求突然又到達服務(wù)端开皿，服務(wù)端誤以為有新的TCP請求，會一直等待篮昧，浪費資源

2. 斷開連接：四次揮手，使用了FIN標(biāo)志笋妥，當(dāng)發(fā)了FIN標(biāo)志后懊昨，這個方向終止連接，但是收到FIN的仍然可以發(fā)數(shù)據(jù)春宣。另外酵颁，先執(zhí)行關(guān)閉的一方將執(zhí)行主動關(guān)閉，否則是被動關(guān)閉月帝。

第一次躏惋，客戶端A發(fā)一個FIN=l，關(guān)閉與服務(wù)端B的數(shù)據(jù)傳輸嚷辅。
第二次簿姨，服務(wù)端收到FIN=l，返回一個ACK=l+1，代表知道客戶端A關(guān)閉數(shù)據(jù)傳輸了扁位。(客戶端已經(jīng)準備取消連接了准潭，但是服務(wù)端還沒有）
第三次，服務(wù)端B關(guān)閉與客戶端A的連接域仇，發(fā)送一個FIN=k給客戶端A刑然。
第四次，客戶端A發(fā)ACK=k+1確認暇务。

三泼掠、http1.0，http1.1和http2的區(qū)別

1.0和1.1的區(qū)別

1.長連接
http1.0默認為短鏈接垦细。需要手動設(shè)置成長連接择镇，而http1.1默認設(shè)置為keep-alive。當(dāng)客戶端和服務(wù)器每進行一次HTTP操作蝠检，就要建立連接沐鼠，任務(wù)結(jié)束中斷了鏈接。要知道創(chuàng)建一個TCP連接要經(jīng)過3次握手叹谁，開銷十分的大饲梭，對傳輸性能也有影響，維持一個長連接十分重要焰檩，可以發(fā)多個請求憔涉。
關(guān)鍵代碼：Connection:keep-alive;

2.緩存策略
http1.00主要依賴強緩存的Expires和協(xié)商緩存Last-Modify作為緩存標(biāo)準，而http1.1引入了更多緩存控制策略入Cache-Control和Etags.

3.Host頭處理
http1.0的請求中不會傳遞host主機名析苫，但是現(xiàn)在一臺物理服務(wù)器可以有多個虛擬主機共享ip兜叨，所以HTTP1.1的請求和響應(yīng)都支持Host，如果請求錯誤會報400 Bad Request衩侥。

4.節(jié)約帶寬
http1.1在請求頭中引入range頭域国旷，允許請求資源的一部分，返回206(partial content)茫死，方便開發(fā)者充分利用帶寬跪但。

1.1和2.0的區(qū)別

1. 多路復(fù)用

http2.0支持多路復(fù)用技術(shù)，同一個連接可以并發(fā)實現(xiàn)多個請求峦萎，并發(fā)請求的數(shù)量級比HTTP1.1要大很多


如何實現(xiàn)多路復(fù)用的屡久？
我們知道TCP的傳輸是靠字節(jié)碼傳輸，每個字節(jié)都是一個一個傳輸爱榔，理論下是不可能并發(fā)請求的被环。所以在并發(fā)請求時，給所有傳輸?shù)陌蛏蠘?biāo)簽详幽，到了服務(wù)器筛欢，服務(wù)器根據(jù)標(biāo)簽再在把數(shù)據(jù)包結(jié)合起來，就可以實現(xiàn)并發(fā)請求。


2. 首部壓縮

對于Http1悴能，Http的報文都是 行揣钦、頭和體，一般體會被gzip壓縮漠酿，但是行和頭不會壓縮冯凹。
HTTP 2.0 使用HPACK算法對header的數(shù)據(jù)進行壓縮，數(shù)據(jù)體積減少炒嘲，減少了數(shù)據(jù)包的數(shù)量宇姚，降低延遲。
HPACK算法主要是維護一份靜態(tài)字典和動態(tài)字典夫凸。
靜態(tài)字典里包換常見的頭的key和常見的key和value浑劳，以字符表示。
例如不會平凡變動的key夭拌，Cookie和UserAgent魔熏，我就用字符代替寫入請求和響應(yīng)代替，就大大減少傳輸數(shù)據(jù)量鸽扁。

3. 服務(wù)器推送(server push）

解釋：在服務(wù)端請求資源之前推送數(shù)據(jù)蒜绽。及服務(wù)器可以根據(jù)一個請求發(fā)多個響應(yīng)，充分利用網(wǎng)絡(luò)空間桶现，減小加載時間躲雅，
為什么：一個網(wǎng)頁有html、樣式表骡和、腳本相赁、圖片、video等等慰于。假如HTTP1.X中一個一個的請求資源钮科，速度慢，且服務(wù)器必須等待一個一個的請求婆赠，然后在發(fā)送跺嗽，網(wǎng)絡(luò)經(jīng)常是空閑的。

4. 二進制分幀層

在應(yīng)用層和傳輸層間增加一個二進制分幀層页藻，會把Http1.x的header和body封裝成HEADERS frame 和DATA frame，改進傳輸性能植兰，實現(xiàn)低延遲和高吞吐量份帐。

四、HTTPs為什么安全

HTTPs=HTTP+SSL(Secure Socket Layer)楣导。
HTTP上建立SSL加密層废境，對數(shù)據(jù)傳輸加密。
HTTP不安全的原因：

  1. HTTP傳輸是明文傳輸，報文都可見噩凹，內(nèi)容可能被竊聽巴元。
    2.無法驗證報文的完整性，有可能在請求或響應(yīng)發(fā)出后驮宴，請求和響應(yīng)被刪改逮刨，但是沒法獲悉。
    3.HTTP協(xié)議是無狀態(tài)的堵泽，服務(wù)端不知道通信方究竟是不是之前的客戶端修己，即請求和響應(yīng)不會對通信方確認 。所以也會有CSRF迎罗。

所以針對以上：

  1. 加密內(nèi)容保隱私：對稱加密+非對稱加密
  2. 數(shù)字簽名：防內(nèi)容篡改
  3. SSL證書：驗證身份睬愤，防偽裝

首先，HTTP需要先和SSL通信纹安，然后SSL再和TCP通信尤辱。

對稱加密+非對稱加密：

對稱加密解密速度快，而非對稱加密是傳輸內(nèi)容不易破解厢岂。所以光督，HTTPS采用如下做法：
發(fā)密文的一方使用對方的公鑰進行對“對稱密鑰”的加密，然后接收方用自己的私鑰解密“對稱密鑰”咪笑，這樣就可以確保較換密鑰的安全可帽。

數(shù)字簽名：
SSL證書：

流程：
1.客戶端發(fā)起一個HTTPs請求，這個請求默認443端口窗怒。
2.服務(wù)端把公鑰證書返回客戶端映跟。
3.客戶端驗證證書，若無效則顯示警告扬虚，若有效則繼續(xù)努隙。
4.客戶端用隨機數(shù)生成器生成所需要的“對稱密鑰”，然后用證書的公鑰加密“對稱密鑰”辜昵，發(fā)給服務(wù)端
5.服務(wù)端用自己的私鑰解密荸镊，得到了對稱密鑰。于是服務(wù)端和客戶端都有了相同的對稱密鑰堪置。

  1. 服務(wù)端開始發(fā)送以對稱密鑰加密的明文響應(yīng)給客戶端躬存。
  2. 客戶端解密，得明文響應(yīng)舀锨。
    8.客戶端發(fā)請求岭洲，會使用密鑰加密的內(nèi)容。服務(wù)端再用密鑰解密坎匿。

五盾剩、斷點續(xù)傳

斷點續(xù)傳就是從文件上次中斷的地方重新下載或者上傳雷激。如果沒有斷點續(xù)傳的功能，每次傳輸出現(xiàn)異掣嫠剑或者用戶暫停傳輸屎暇，都會去重頭下載，浪費時間根悼。HTTP1.1開始支持斷電續(xù)傳。
一般用到Range和Content-Range字段頭格嗅。用于獲取服務(wù)器中大文件的一部分內(nèi)容番挺。（指定開始-結(jié)束）

  1. 客戶端下1024K文件，已下載了512k
    2.網(wǎng)絡(luò)中斷屯掖，客戶端請求續(xù)傳玄柏，在請求頭寫：Range：bytes=512000-
    3.服務(wù)器收到斷點續(xù)傳，從512開始傳輸贴铜，并在響應(yīng)頭里寫Content-Range:bytes:512000-/102400
    此時狀態(tài)碼為206（partial content）
    當(dāng)然有時候在續(xù)傳時粪摘，url對應(yīng)的文件在服務(wù)端已經(jīng)更新了，就需要從新下載绍坝，所以在續(xù)傳時徘意，請求頭要有If-modified-since和If-none-match的標(biāo)注，檢驗是否改動轩褐，若改動椎咧，則返回新的文件的全部數(shù)據(jù)（200），否則206把介。

六勤讽、堆、棧拗踢、隊列

堆（heap）

堆（heap）是指程序運行時申請的動態(tài)內(nèi)存脚牍，在JS運行時用來存放對象。

棧（stack）

棧（stack）遵循的原則是“先進后出”巢墅，JS種的基本數(shù)據(jù)類型與指向?qū)ο蟮牡刂反娣旁跅?nèi)存中诸狭，此外還有一塊棧內(nèi)存用來執(zhí)行JS主線程–執(zhí)行棧（execution context stack）

隊列（queue）

隊列（queue）遵循的原則是“先進先出”，JS中除了主線程之外還存在兩個“任務(wù)隊列”（微任務(wù)隊列microTask和宏任務(wù)隊列macroTask）君纫。
微任務(wù)：promise.then
宏任務(wù)：setTimeout, setInterval

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末驯遇，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子蓄髓，更是在濱河造成了極大的恐慌仔燕，老刑警劉巖知染，帶你破解...
    沈念sama閱讀 218,284評論 6贊 506
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件揭芍，死亡現(xiàn)場離奇詭異幻件，居然都是意外死亡，警方通過查閱死者的電腦和手機好乐，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,115評論 3贊 395
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門匾竿，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人蔚万，你說我怎么就攤上這事岭妖。” “怎么了反璃？”我有些...
    開封第一講書人閱讀 164,614評論 0贊 354
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵昵慌，是天一觀的道長。 經(jīng)常有香客問我淮蜈，道長斋攀，這世上最難降的妖魔是什么？ 我笑而不...
    開封第一講書人閱讀 58,671評論 1贊 293
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任梧田，我火速辦了婚禮淳蔼，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘裁眯。我一直安慰自己鹉梨，他們只是感情好，可當(dāng)我...
    茶點故事閱讀 67,699評論 6贊 392
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布穿稳。 她就那樣靜靜地躺著存皂，像睡著了一般。 火紅的嫁衣襯著肌膚如雪逢艘。 梳的紋絲不亂的頭發(fā)上旦袋，一...
    開封第一講書人閱讀 51,562評論 1贊 305
  • 城市分裂傳說
    那天，我揣著相機與錄音埋虹，去河邊找鬼猜憎。 笑死，一個胖子當(dāng)著我的面吹牛搔课，可吹牛的內(nèi)容都是我干的胰柑。 我是一名探鬼主播，決...
    沈念sama閱讀 40,309評論 3贊 418
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼爬泥，長吁一口氣：“原來是場噩夢啊……” “哼柬讨！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起袍啡，我...
    開封第一講書人閱讀 39,223評論 0贊 276
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤踩官，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后境输，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體蔗牡，經(jīng)...
    沈念sama閱讀 45,668評論 1贊 314
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡颖系，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,859評論 3贊 336
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了辩越。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片嘁扼。...
    茶點故事閱讀 39,981評論 1贊 348
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖黔攒，靈堂內(nèi)的尸體忽然破棺而出趁啸，到底是詐尸還是另有隱情，我是刑警寧澤督惰，帶...
    沈念sama閱讀 35,705評論 5贊 347
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布不傅，位于F島的核電站，受9級特大地震影響赏胚，放射性物質(zhì)發(fā)生泄漏访娶。R本人自食惡果不足惜，卻給世界環(huán)境...
    茶點故事閱讀 41,310評論 3贊 330
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一栅哀、第九天 我趴在偏房一處隱蔽的房頂上張望震肮。 院中可真熱鬧，春花似錦留拾、人聲如沸戳晌。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,904評論 0贊 22
  • 一樁弒父案痴柔，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽沦偎。三九已至，卻和暖如春咳蔚，著一層夾襖步出監(jiān)牢的瞬間豪嚎，已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,023評論 1贊 270
  • 情欲美人皮
    我被黑心中介騙來泰國打工谈火， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留侈询，地道東北人。 一個月前我還...
    沈念sama閱讀 48,146評論 3贊 370
  • 代替公主和親
    正文 我出身青樓糯耍，卻偏偏與公主長得像扔字，于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子温技，可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 44,933評論 2贊 355