HTTP/HTML/瀏覽器

時間 2019-12-01

標籤 http html 瀏覽器欄目 HTTP/TCP 简体版

原文原文鏈接

　　說一下HTTP和HTTPSjavascript

HTTP的SSL加密是在傳輸層實現的php

（1）HTTP和HTTPS的基本概念html

　　HTTP：超文本傳輸協議，是互聯網上應用最普遍的一種網絡協議，是一個客戶端和服務器端請求和響應的標準（TCP），用於從www服務器傳輸超文本到本地瀏覽器的傳輸協議，它可使瀏覽器更加高效，使網絡傳輸減小。前端

　　HTTPS：是以安全爲目的的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。java

　　HTTPS的主要的做用就是創建一個信息安全通道，來確保數組的傳輸，確保網站的真是性。web

（2）HTTP和HTTPS的區別json

　　HTTP擦混輸數據都是未加密的，也就是明文，HTTPS是由HTTP和SSL協議構建的可進行加密傳輸和身份認證的網絡協議，比HTTP協議安全性更高api

　　主要區別：數組

　　HTTPS協議須要ca證書，費用很高。瀏覽器

　　HTTP是超文本傳輸協議，信息是明文，而HTTPS是具備安全性的SSL加密傳輸協議。

　　端口號不一樣，HTTP的默認端口號是80，而HTTPS的默認端口號是443.

　　HTTP鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸身份認證的網絡協議，比HTTP的協議安全。

　　TCp三次握手，一句話概述

客戶端和服務器端都要直到本身可收發，所以須要三次握手

　　TCP和UDP的區別

（1）TCP是面向鏈接的，udp是無鏈接的即發送數據前不須要先創建連接。

（2）TCP提供可靠的服務。也就是說，經過TCP鏈接傳送的數據，無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，即不保證可靠交付。而且由於tcp可靠，面向鏈接，不會丟失數據所以適合大數據量的交換。

（3）TCP是面向字節流，UDP面向報文，而且網絡出現擁塞不會使得發送速率下降（所以會出現丟包，對實時的應用好比IP電話和視頻會議等）。

（4）TCP只能是1對1的，UDP支持1對1,1對多。

（5）TCP的首部較大爲20字節，而UDP只有8字節。

（6）TCP是面向鏈接的可靠性傳輸，而UDP是不可靠的。

　　WebSocket的實現和應用

WebSocket是HTML5中的協議，支持持久連續，http協議不支持持久性鏈接。Http1.0和HTTP1.1都不支持持久性的連接，HTTP1.1中的keep-alive，將多個http請求合併爲1個

　　Http請求方式，head方式

head：相似於get請求，只不過返回的響應中沒有具體的內容，用戶獲取報頭

options：容許客戶端查看服務器的性能，好比說服務器支持的請求方式等等。

　　說一下Web Quality（無障礙）

可以被殘障人士使用的網站才能稱得上一個易用的（易訪問的）網站。

使用alt屬性：

有時候瀏覽器會沒法顯示圖像。具體的緣由有：

　　用戶關閉了圖像顯示

　　瀏覽器是不支持圖形顯示的迷你瀏覽器

　　瀏覽器是語音瀏覽器（供盲人和弱視人羣使用）
　　若是您使用了alt 屬性，那麼瀏覽器至少能夠顯示或讀出有關圖像的描述。

　　幾個很實用的BOM屬性對象方法

　　什麼是BOM？BOM是瀏覽器對象。

　　建立的BOM的屬性：

(1)location對象

location.href-- 返回或設置當前文檔的URL
location.search -- 返回URL中的查詢字符串部分。如 http://www.dreamdu.com/dreamdu.php?id=5&name=dreamdu 返回包括(?)後面的內容?id=5&name=dreamdu
location.hash -- 返回URL#後面的內容，若是沒有#，返回空
location.host -- 返回URL中的域名部分，例如www.dreamdu.com
location.hostname -- 返回URL中的主域名部分，例如dreamdu.com
location.pathname -- 返回URL的域名後的部分。例如 http://www.dreamdu.com/xhtml/ 回/xhtml/
location.port -- 返回URL中的端口部分。例如 http://www.dreamdu.com:8080/xhtml/ 返回8080
location.protocol -- 返回URL中的協議部分。例如 http://www.dreamdu.com:8080/xhtml/ 返回(//)前面的內容http:
location.assign -- 設置當前文檔的URL
location.replace() -- 設置當前文檔的URL，而且在history對象的地址列表中移除這個URL location.replace(url);
location.reload() -- 重載當前頁面

(2)history對象

history.go() -- 前進或後退指定的頁面數 history.go(num);
history.back() -- 後退一頁
history.forward() -- 前進一頁

(3)Navigator對象

navigator.userAgent -- 返回用戶代理頭的字符串表示(就是包括瀏覽器版本信息等的字符串)
navigator.cookieEnabled -- 返回瀏覽器是否支持(啓用)cookie

　　說一下HTML5 drag api

dragstart：事件主體是被拖放元素，在開始拖放被拖放元素時觸發，。

darg：事件主體是被拖放元素，在正在拖放被拖放元素時觸發。

dragenter：事件主體是目標元素，在被拖放元素進入某元素時觸發。

dragover：事件主體是目標元素，在被拖放在某元素內移動時觸發。

dragleave：事件主體是目標元素，在被拖放元素移出目標元素是觸發。

drop：事件主體是目標元素，在目標元素徹底接受被拖放元素時觸發。

dragend：事件主體是被拖放元素，在整個拖放操做結束時觸發

　　說一下HTTP2.0

提高訪問速度（能夠對於，請求資源所需時間更少，訪問速度更快，相比http1.0）

容許多路複用：多路複用容許同時經過單一的HTTP/2鏈接發送多重請求-響應信息。改善了：在http1.1中，瀏覽器客戶端在同一時間，針對同一域名下的請求有必定數量限制（鏈接數量），超過限制會被阻塞。

二進制分幀：HTTP2.0會將全部的傳輸信息分割爲更小的信息或者幀，並對他們進行二進制編碼

首部壓縮

服務器端推送

　　補充400和40一、403狀態碼

(1)400狀態碼：請求無效

產生緣由：

前端提交數據的字段名稱和字段類型與後臺的實體沒有保持一致

前端提交到後臺的數據應該是json字符串類型，可是前端沒有將對象JSON.stringify轉化成字符串。

解決方法：

對照字段的名稱，保持一致性

將obj對象經過JSON.stringify實現序列化

(2)401狀態碼：當前請求須要用戶驗證

(3)403狀態碼：服務器已經獲得請求，可是拒絕執行

　　Cookie、sessionStorage、localStorage的區別

共同點：都是保存在瀏覽器端，而且是同源的

　　Cookie：cookie數據始終在同源的http請求中攜帶（即便不須要），即cookie在瀏覽器和服務器間來回傳遞。而sessionStorage和localStorage不會自動把數據發給服務器，僅在本地保存。cookie數據還有路徑（path）的概念，能夠限制cookie只屬於某個路徑下,存儲的大小很小隻有4K左右。（key：能夠在瀏覽器和服務器端來回傳遞，存儲容量小，只有大約4K左右）

　　sessionStorage：僅在當前瀏覽器窗口關閉前有效，天然也就不可能持久保持，　　　　

　　localStorage：始終有效，窗口或瀏覽器關閉也一直保存，所以用做持久數據；cookie只在設置的cookie過時時間以前一直有效，即便窗口或瀏覽器關閉。（key：自己就是一個回話過程，關閉瀏覽器後消失，session爲一個回話，當頁面不一樣即便是同一頁面打開兩次，也被視爲同一次回話）

　　localStorage：localStorage 在全部同源窗口中都是共享的；cookie也是在全部同源窗口中都是共享的。（key：同源窗口都會共享，而且不會失效，無論窗口或者瀏覽器關閉與否都會始終生效）

　　對HTML的語義化的理解

HTML5語義化標籤是指正確的標籤包含了正確的內容，結構良好，便於閱讀，好比nav表示導航條，相似的還有article、header、footer等等標籤。

　　Doctype做用?嚴格模式與混雜模式如何區分？它們有何意義?

Doctype聲明於文檔最前面，告訴瀏覽器以何種方式來渲染頁面，這裏有兩種模式，嚴格模式和混雜模式。

嚴格模式的排版和JS 運做模式是以該瀏覽器支持的最高標準運行。

混雜模式，向後兼容，模擬老式瀏覽器，防止瀏覽器沒法兼容頁面。

　　Cookie如何防範XSS攻擊

XSS（跨站腳本攻擊）是指攻擊者在返回的HTML中嵌入javascript腳本，爲了減輕這些攻擊，須要在HTTP頭部配上，set-cookie：

httponly-這個屬性能夠防止XSS,它會禁止javascript腳原本訪問cookie。

　　Cookie和session的區別

cookie保存在客戶端，而session保存在服務端

cookie不是很安全，別人能夠分析存放在本地的COOKIE並進行COOKIE欺騙

考慮到安全應當使用session。

session會在必定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能

考慮到減輕服務器性能方面，應當使用COOKIE。

單個cookie保存的數據不能超過4K，不少瀏覽器都限制一個站點最多保存20個cookie。

　　介紹知道的http返回的狀態碼

100 Continue 繼續。客戶端應繼續其請求

101 Switching Protocols 切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到HTTP的新版本協議

200 OK 請求成功。通常用於GET與POST請求

201 Created 已建立。成功請求並建立了新的資源

202 Accepted 已接受。已經接受請求，但未處理完成

203 Non-Authoritative Information 非受權信息。請求成功。但返回的meta信息不在原始的服務器，而是一個副本

204 No Content 無內容。服務器成功處理，但未返回內容。在未更新網頁的狀況下，可確保瀏覽器繼續顯示當前文檔

205 Reset Content 重置內容。服務器處理成功，用戶終端（例如：瀏覽器）應重置文檔視圖。可經過此返回碼清除瀏覽器的表單域

206 Partial Content 部份內容。服務器成功處理了部分GET請求

300 Multiple Choices 多種選擇。請求的資源可包括多個位置，相應可返回一個資源特徵與地址的列表用於用戶終端（例如：瀏覽器）選擇

301 Moved Permanently 永久移動。請求的資源已被永久的移動到新URI，返回信息會包括新的URI，瀏覽器會自動定向到新URI。從此任何新的請求都應使用新的URI代替

302 Found 臨時移動。與301相似。但資源只是臨時被移動。客戶端應繼續使用原有URI

303 See Other 查看其它地址。與301相似。使用GET和POST請求查看

304 Not Modified 未修改。所請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。客戶端一般會緩存訪問過的資源，經過提供一個頭信息指出客戶端但願只返回在指定日期以後修改的資源

305 Use Proxy 使用代理。所請求的資源必須經過代理訪問

306 Unused 已經被廢棄的HTTP狀態碼

307 Temporary Redirect 臨時重定向。與302相似。使用GET請求重定向

400 Bad Request 客戶端請求的語法錯誤，服務器沒法理解

401 Unauthorized 請求要求用戶的身份認證

402 Payment Required 保留，未來使用

403 Forbidden 服務器理解請求客戶端的請求，可是拒絕執行此請求

404 Not Found 服務器沒法根據客戶端的請求找到資源（網頁）。經過此代碼，網站設計人員可設置"您所請求的資源沒法找到"的個性頁面

405 Method Not Allowed 客戶端請求中的方法被禁止

406 Not Acceptable 服務器沒法根據客戶端請求的內容特性完成請求

407 Proxy Authentication Required 請求要求代理的身份認證，與401相似，但請求者應當使用代理進行受權

408 Request Time-out 服務器等待客戶端發送的請求時間過長，超時

409 Conflict 服務器完成客戶端的PUT請求是可能返回此代碼，服務器處理請求時發生了衝突

410 Gone 客戶端請求的資源已經不存在。410不一樣於404，若是資源之前有如今被永久刪除了可以使用410代碼，網站設計人員可經過301代碼指定資源的新位置

411 Length Required 服務器沒法處理客戶端發送的不帶Content-Length的請求信息

412 Precondition Failed 客戶端請求信息的先決條件錯誤

413 Request Entity Too Large 因爲請求的實體過大，服務器沒法處理，所以拒絕請求。爲防止客戶端的連續請求，服務器可能會關閉鏈接。若是隻是服務器暫時沒法處理，則會包含一個Retry-After的響應信息

414 Request-URI Too Large 請求的URI過長（URI一般爲網址），服務器沒法處理

415 Unsupported Media Type 服務器沒法處理請求附帶的媒體格式

416 Requested range not satisfiable 客戶端請求的範圍無效

417 Expectation Failed 服務器沒法知足Expect的請求頭信息

500 Internal Server Error 服務器內部錯誤，沒法完成請求

501 Not Implemented 服務器不支持請求的功能，沒法完成請求

502 Bad Gateway 做爲網關或者代理工做的服務器嘗試執行請求時，從遠程服務器接收到了一個無效的響應

503 Service Unavailable 因爲超載或系統維護，服務器暫時的沒法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中

504 Gateway Time-out 充當網關或代理的服務器，未及時從遠端服務器獲取請求

505 HTTP Version not supported 服務器不支持請求的HTTP協議的版本，沒法完成處理

　　前端的優化

下降請求量：合併資源，減小HTTP 請求數，minify / gzip 壓縮，webP，lazyLoad。

加快請求速度：預解析DNS，減小域名數，並行加載，CDN 分發。

緩存：HTTP 協議緩存請求，離線緩存 manifest，離線數據緩存localStorage。

渲染：JS/CSS優化，加載順序，服務端渲染，pipeline。

　　GET和POst的區別

get參數經過url傳遞，post放在request body中。

get請求在url中傳遞的參數是有長度限制的，而post沒有。

get比post更不安全，由於參數直接暴露在url中，因此不能用來傳遞敏感信息。

get請求只能進行url編碼，而post支持多種編碼方式

get請求會瀏覽器主動cache，而post支持多種編碼方式。

get請求參數會被完整保留在瀏覽歷史記錄裏，而post中的參數不會被保留。

GET和POST本質上就是TCP連接，並沒有差異。可是因爲HTTP的規定和瀏覽器/服務器的限制，致使他們在應用過程當中體現出一些不一樣。

GET產生一個TCP數據包；POST產生兩個TCP數據包。

　　301和302的區別

　　HTTP支持的方法

GET, POST, HEAD, OPTIONS, PUT, DELETE, TRACE, CONNECT

　　狀態碼304和 200

　　瀏覽器在生成頁面的時候，會生成那兩顆樹？

構造兩棵樹，DOM樹和CSSOM規則樹

當瀏覽器接收到服務器相應來的HTML文檔後，會遍歷文檔節點，生成DOM樹，

CSSOM規則樹由瀏覽器解析CSS文件生成

　　**輸入URL到頁面加載顯示完成發生了什麼?**

DNS解析

TCP鏈接

發送HTTP請求

服務器處理請求並返回HTTP報文

瀏覽器解析渲染頁面

鏈接結束

　　瀏覽器緩存機制

緩存分爲兩種：強緩存和協商緩存，根據響應的header內容來決定。

強緩存相關字段有expires，cache-control。若是cache-control與expires同時存在的話，cache-control的優先級高於expires。

協商緩存相關字段有Last-Modified/If-Modified-Since，Etag/If-None-Match

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。