1. 程式人生 > 其它 >瀏覽器 重定向次數限制_瀏覽器

瀏覽器 重定向次數限制_瀏覽器

技術標籤:瀏覽器 重定向次數限制

點選藍色名字關注181fa6231d57f84ea2cde83ad7626f4f.gif獲取最新文章

OSI七層與TCP/IP五層模型

  • OSI七層模型

    1.應用層

    2.表示層

    3.會話層

    4.傳輸層

    5.網路層

    6.資料鏈路層

    7.物理層

  • TCP/IP五層模型

    1.應用層:TFTP,HTTP,SNMP,FTP,SMTP,DNS,Telnet

    2.傳輸層:TCP,UDP

    3.網路層:IP,ICMP,RIP,OSPF,BGP,IGMP

    4.資料鏈路層:SLIP,CSLIP,PPP,ARP,RARP,MTU

    5.物理層

應用層的協議哪些是基於TCP協議的,哪些是基於UDP協議的

基於TCP協議的
  • FTP(檔案傳輸協議):定義了檔案傳輸協議,使用21埠。

  • TELNET(遠端登陸協議):一種用於遠端登陸的埠,使用23埠,使用者可以以自己的身份遠端連線到計算機上,可提供基於DOS模式下的通訊服務。

  • SMTP(簡單郵件傳輸協議):郵件傳送協議,用於傳送郵件。伺服器開放的是25號埠。

  • POP3(郵件讀取協議):它是和SMTP對應,POP3用於接收郵件。POP3協議所用的是110埠。

  • HTTP(超文字傳輸協議):是從Web伺服器傳輸超文字到本地瀏覽器的傳送協議。

  • HTTPS(超文字傳輸安全協議)

基於UDP協議的
  • TFTP(簡單檔案傳輸協議):該協議在熟知埠69上使用UDP服務。

  • SNMP(簡單網路管理協議):使用161號埠,是用來管理網路裝置的。由於網路裝置很多,無連線的服務就體現出其優勢。

  • BOOTP(載入程式協議,DHCP的前身):應用於無盤裝置

  • DHCP(動態主機配置協議):是一個區域網的網路協議

  • RIP(路由資訊協議):基於距離向量演算法的路由協議,利用跳數來作為計量標準。

  • IGMP(Internet組管理協議)

基於TCP和UDP協議的
  • DNS(域名系統):DNS區域傳輸的時候使用TCP協議。域名解析時使用UDP協議。DNS用的是53號埠。

  • ECHO(迴繞協議)

HTTP 狀態碼

  1. 1XX 資訊性狀態碼

  • 100 繼續

  • 101 切換協議

2XX 成功狀態碼

  • 200 OK 成功處理了請求

  • 204 No Content 請求處理成功,但沒有資源可返回

  • 206 Partial Content 請求資源的某一部分

3XX 重定向狀態碼

  • 301 永久性重定向,表示請求的資源已被分配了新的 URI

  • 302 臨時性重定向,資源的 URL 已臨時定位到其他位置

  • 303 告訴客戶端應該用另一個 URL 獲取資源

  • 304 表示客戶端傳送附帶條件的請求時,伺服器端允許請求訪問資源,但未滿足條件的情況

4XX 客戶端錯誤狀態碼

  • 400 表示請求報文中存在語法錯誤

  • 401 未授權

  • 403 伺服器拒絕了請求

  • 404 伺服器無法找到所請求的 URL

5XX 伺服器錯誤狀態碼

  • 500 內部伺服器錯誤

  • 502 錯誤閘道器

  • 503 伺服器暫時處於超負載或正在進行停機維護,現在無法處理請求。

  • 504 響應超時

HTTP 與 HTTPS 的區別

  1. HTTP 傳輸的資料都是未加密的,也就是明文的,HTTPS 協議是由 HTTP 和 SSL 協議構建的可進行加密傳輸和身份認證的網路協議,比 HTTP 協議的安全性更高。

  2. HTTPS 協議需要 CA 證書,費用較高;

  3. 使用不同的連結方式,埠也不同,一般而言,HTTP 協議的埠為 80,HTTPS 的埠為 443;

HTTPS 協議的工作原理

  1. 客戶使用 HTTPS URL 訪問伺服器,則要求 web 伺服器建立 SSL 連結。

  2. web 伺服器接收到客戶端的請求之後,會將網站的證書(證書中包含了公鑰),返回給客戶端。

  3. 客戶端和 web 伺服器端開始協商 SSL 連結的安全等級,也就是加密等級。

  4. 客戶端瀏覽器通過雙方協商一致的安全等級,建立會話金鑰,然後通過網站的公鑰來加密會話金鑰,並傳送給網站。

  5. web 伺服器通過自己的私鑰解密出會話金鑰。

  6. web 伺服器通過會話金鑰加密與客戶端之間進行通訊。

HTTP/2.0 特性

參考連結:HTTP/2 相比 1.0 有哪些重大改進?

  1. 首部壓縮

  2. 多路複用

  3. 二進位制分幀

  4. 服務端推送

TCP 和 UDP 之間的區別

TCP:傳輸控制協議 UDP:使用者資料報協議

  1. TCP 是面向連線的,UDP 是無連線的即傳送資料前不需要先建立連結;

  2. TCP 提供可靠的服務。也就是說,通過 TCP 連線傳送的資料,無差錯,不丟失,不重複,且按序到達;UDP 盡最大努力交付,即不保證可靠交付。

  3. TCP 是面向位元組流,UDP 面向報文;

  4. TCP 只能是 1 對 1 的,UDP 支援 1 對 1,1 對多;

  5. TCP 的首部較大為 20 位元組,而 UDP 只有 8 位元組;

TCP 的三次握手和四次揮手

對稱加密和非對稱加密的區別

WebSocket 協議

參考連結:HTML5 WebSocket

WebSocket 是 HTML5 開始提供的一種在單個 TCP 連線上進行全雙工通訊的協議。

WebSocket 使得客戶端和伺服器之間的資料交換變得更加簡單,允許服務端主動向客戶端推送資料。在 WebSocket API 中,瀏覽器和伺服器只需要完成一次握手,兩者之間就直接可以建立永續性的連線,並進行雙向資料傳輸。

現在,很多網站為了實現推送技術,所用的技術都是 Ajax 輪詢。輪詢是在特定的的時間間隔(如每 1 秒),由瀏覽器對伺服器發出 HTTP 請求,然後由伺服器返回最新的資料給客戶端的瀏覽器。這種傳統的模式帶來很明顯的缺點,即瀏覽器需要不斷的向伺服器發出請求,然而 HTTP 請求可能包含較長的頭部,其中真正有效的資料可能只是很小的一部分,顯然這樣會浪費很多的頻寬等資源。

應用場景:實現即時通訊:如股票交易行情分析、聊天室、線上遊戲等,替代輪詢和長輪詢

什麼是瀏覽器的同源政策

我對瀏覽器的同源政策的理解是,一個域下的 js 指令碼在未經允許的情況下,不能夠訪問另一個域的內容。這裡的同源的指的是兩個

域的協議、域名、埠號必須相同,否則則不屬於同一個域。

同源政策主要限制了三個方面

第一個是當前域下的 js 指令碼不能夠訪問其他域下的 cookie、localStorage 和 indexDB。

第二個是當前域下的 js 指令碼不能夠操作訪問其他域下的 DOM。

第三個是當前域下 ajax 無法傳送跨域請求。

同源政策的目的主要是為了保證使用者的資訊保安,它只是對 js 指令碼的一種限制,並不是對瀏覽器的限制,對於一般的 img、或者

script 指令碼請求都不會有跨域的限制,這是因為這些操作都不會通過響應結果來進行可能出現安全問題的操作。

HTTP 請求的方式

  1. GET:請求指定的頁面資訊,並返回實體主體。

  2. HEAD:類似於 GET 請求,只不過返回的響應中沒有具體的內容,用於獲取報頭

  3. POST:向指定資源提交資料進行處理請求(例如提交表單或者上傳檔案)。資料被包含在請求體中。POST 請求可能會導致新的資源的建立和/或已有資源的修改。

  4. PUT:從客戶端向伺服器傳送的資料取代指定的文件的內容。

  5. DELETE:請求伺服器刪除指定的頁面。

  6. CONNECT:HTTP/1.1 協議中預留給能夠將連線改為管道方式的代理伺服器。

  7. OPTIONS:允許客戶端檢視伺服器的效能。

  8. TRACE:回顯伺服器收到的請求,主要用於測試或診斷。

GET 和 POST 的區別

兩者本質上都是 TCP 連結

  1. get 引數通過 url 傳遞,post 放在請求體 (request body) 中。

  2. get 請求在 url 中傳遞的引數是有長度限制的,而 post 沒有。

  3. get 比 post 更不安全,因為引數直接暴露在 url 中,所以不能用來傳遞敏感資訊。

  4. get 請求只能進行 url 編碼,而 post 支援多種編碼方式。

  5. get 請求引數會被完整保留在瀏覽歷史記錄裡,而 post 中的引數不會被保留。

  6. get 產生一個 TCP 資料包;post 產生兩個 TCP 資料包。
    對於 get 方式的請求,瀏覽器會把 http header 和 data 一併傳送出去,伺服器響應 200(返回資料);
    而對於 post,瀏覽器先發送 header,伺服器響應 100 continue,瀏覽器再發送 data,伺服器響應 200 ok(返回資料)。

瀏覽器輸入 URL 之後發生了什麼

參考連結:在瀏覽器輸入 URL 回車之後發生了什麼(超詳細版)

  1. DNS 解析

  2. TCP 連線

  3. 傳送 HTTP 請求

  4. 伺服器處理請求並返回 HTTP 報文

  5. 瀏覽器解析渲染頁面

  6. 連線結束

DNS 的具體過程

  1. 輸入 IP,此時電腦傳送一個 DNS 請求到本地 DNS 伺服器(一般是網路接入服務商提供 eg:電信,移動)

  2. 本地 DNS 伺服器會首先查詢它的快取記錄,若有,則直接返回結果,若沒有,本地 DNS 伺服器還要向 DNS 根伺服器進行查詢;

  3. DNS 根伺服器沒有記錄具體域名和 IP 地址的對應關係,而是告訴本地 DNS 伺服器,可到域伺服器上繼續查詢,並給出域伺服器地址

  4. 本地伺服器繼續向域伺服器發出請求,返回域名的解析伺服器地址

  5. 本地 DNS 向域名解析伺服器發出請求,收到域名與 IP 地址對應關係

  6. 本地 DNS 伺服器將 IP 地址返回電腦,且儲存副本到快取已備下次查詢

Cookie 和 WebStorage(SessionStorage 和 LocalStorage)的區別

  1. 都會在瀏覽器端儲存,有大小限制,同源限制

  2. cookie 會在請求時傳送到伺服器,作為會話標識,伺服器可修改 cookie;web storage 不會發送到伺服器

  3. cookie 有 path 概念,子路徑可以訪問父路徑 cookie,父路徑不能訪問子路徑 cookie

  4. 有效期:cookie 在設定的有效期內有效,預設為瀏覽器關閉;sessionStorage 在視窗關閉前有效;localStorage 長期有效,直到使用者刪除

  5. 作用域不同 sessionStorage:不在不同的瀏覽器視窗中共享,即使是同一個頁面;localStorage:在所有同源視窗都是共享的;cookie:也是在所有同源視窗中共享的

  6. 儲存大小不同:cookie 資料不能超過 4K;webStorage 雖然也有儲存大小的限制,但是比 cookie 大得多,可以達到 5M 或更大

cookie 和 session 的區別

1.儲存位置不同:

cookie 資料存放在客戶的瀏覽器上

session 資料放在伺服器上。

2.儲存容量不同:

單個 cookie 儲存的資料不能超過 4K,一個站點最多儲存 20 個 cookie。

對於 session 來說並沒有上限,但出於對伺服器端的效能考慮,session 內不要存放過多的東西,並且設定 session 刪除機制。

3.儲存方式不同:

cookie 中只能保管 ASCII 字串,並需要通過編碼方式儲存為 Unicode 字元或者二進位制資料。

session 中能夠儲存任何型別的資料,包括且不限於 string,integer,list,map 等。

4.隱私策略不同

cookie 對客戶端是可見的,別有用心的人可以分析存放在本地的 cookie 並進行 cookie 欺騙,所以它是不安全的。

session 儲存在伺服器上,不存在敏感資訊洩漏的風險。

5.有效期不同

cookie 保管在客戶端,不佔用伺服器資源。對於併發使用者十分多的網站,cookie 是很好的選擇。

session 是保管在伺服器端的,每個使用者都會產生一個 session。假如併發訪問的使用者十分多,會產生十分多的 session,耗費大量的記憶體。

能設定或讀取子域的cookie嗎

不行! 只能向當前域或者更高階域設定cookie

例如 client.com 不能向 a.client.com 設定cookie, 而 a.client.com 可以向 client.com 設定cookie

讀取cookie情況同上

客戶端設定cookie與服務端設定cookie有什麼區別

無論是客戶端還是服務端, 都只能向自己的域或者更高階域設定cookie,例如 client.com 不能向 server.com 設定cookie, 同樣 server.com 也不能向 client.com 設定cookie

服務端可以設定httpOnly: true, 帶有該屬性的cookie客戶端無法讀取

客戶端只會帶上與請求同域的cookie, 例如 client.com/index.html 會帶上 client.com 的cookie,server.com/app.js 會帶上 server.com 的cookie, 並且也會帶上httpOnly的cookie

同域/跨域ajax請求到底會不會帶上cookie

fetch在預設情況下, 不管是同域還是跨域ajax請求都不會帶上cookie, 只有當設定了 credentials 時才會帶上該ajax請求所在域的cookie, 服務端需要設定響應頭Access-Control-Allow-Credentials: true, 否則瀏覽器會因為安全限制而報錯, 拿不到響應

axios和jQuery在同域ajax請求時會帶上cookie, 跨域請求不會, 跨域請求需要設定withCredentials和服務端響應頭Access-Control-Allow-Credentials

  • fetch 設定 credentials 使fetch帶上cookie

    fetch(url, {

    credentials: "include", // include, same-origin, omit

    })

  • axios 設定 withCredentials 使axios帶上cookie

    axios.get('http://server.com', {withCredentials: true})

  • jQuery 設定 withCredentials

    $.ajax({

    method: 'get',

    url: 'http://server.com',

    xhrFields: {

    withCredentials: true

    }

    })

前端攻擊技術

XSS攻擊(cross-site script)
  1. XSS攻擊形式:

    主要是通過html標籤注入,篡改網頁,插入惡意的指令碼,前端可能沒有經過嚴格的校驗直接就進到資料庫,資料庫又通過前端程式又回顯到瀏覽器

    例如一個留言板:

    如果內容是

    hello!<script type="type/javascript src="惡意網址">script>

    這樣會通過前端程式碼來執行js指令碼,如果這個惡意網址通過cookie獲得了使用者的私密資訊,那麼使用者的資訊就被盜了

  2. 攻擊的目的:

    攻擊者可通過這種方式拿到使用者的一些資訊,例如cookie 獲取敏感資訊,甚至自己建網站,做一些非法的操作等;或者,拿到資料後以使用者的身份進行勒索,發一下不好的資訊等。

  3. 攻擊防禦

    方法1:cookie中設定 HttpOnly 屬性

    方法2:首先前端要對使用者輸入的資訊進行過濾,可以用正則,通過替換標籤的方式進行轉碼或解碼,例如<> 空格 & ” “”等替換成html編碼

    htmlEncodeByRegExp:function (str){

    var s = "";

    if(str.length == 0) return "";

    s = str.replace(/&/g,"&");

    s = s.replace(/,");

    s = s.replace(/>/g,">");

    s = s.replace(/ /g,"");

    s = s.replace(/\'/g,"'");

    s = s.replace(/\"/g,""");

    return s;

    }

CSRF攻擊(cross site request forgery,跨站請求偽造)
  1. CSRF攻擊形式:

    CSRF也是一種網路攻擊方式,比起xss攻擊,是另外一種更具危險性的攻擊方式,xss是站點使用者進行攻擊,而csrf是通過偽裝成站點使用者進行攻擊,而且防範的資源也少,難以防範

    csrf攻擊形式:攻擊者盜用使用者的身份資訊,並以使用者的名義進行傳送惡意的請求等,例如發郵件,盜取賬號等非法手段

    例如:你登入網站,並在本地種下了cookie

    如果在沒退出該網站的時候 不小心訪問了惡意網站,而且這個網站需要你發一些請求等

    此時,你是攜帶cookie進行訪問的,那麼你的種在cookie裡的資訊就會被惡意網站捕捉到,那麼你的資訊就被盜用,導致一些不法分子做一些事情

  2. 攻擊防禦:

    在HTTP頭中有Referer欄位,他記錄該HTTP請求的來源地址,如果跳轉的網站與來源地址相符,那就是合法的,如果不符則可能是csrf攻擊,拒絕該請求

    這種的話在請求的時候加一個token,值可以是隨機產生的一段數字,

    token是存入資料庫之後,後臺返給客戶端的,如果客戶端再次登入的時候,

    後臺發現token沒有,或者通過查詢資料庫不正確,那麼就拒絕該請求

    如果想防止一個賬號避免在不同的機器上登入,那麼我們就可以通過token來判斷,

    如果a機器登入後,我們就將使用者的token從資料庫清除,從新生成,

    那麼另外一臺b機器在執行操作的時候,token就失效了,只能重新登入,這樣就可以防止兩臺機器登同一賬號

    如果說通過每次請求的時候都得加token那麼各個介面都得加很麻煩,

    那麼我們通過http的請求頭來設定token

    例如:

    $.ajax({

    url: '/v1/api',

    dataType: 'json',

    data: param,

    type:'post',

    headers: {'Accept':'application/json','Authorization':tokenValue}

    success:function(res){

    console.log(res)

    }

    })

  • 在HTTP頭中自定義屬性並驗證

  • 在請求地址中新增token並驗證

  • 驗證HTTP Referer欄位

瀏覽器快取機制

參考連結:HTTP 強快取和協商快取

瀏覽器快取分為:強快取和協商快取

在瀏覽器第一次發起請求時,本地無快取,向 web 伺服器傳送請求,伺服器起端響應請求,瀏覽器端快取。在第一次請求時,伺服器會將頁面最後修改時間通過 Last-Modified 標識由伺服器傳送給客戶端,客戶端記錄修改時間;伺服器還會生成一個 Etag,併發送給客戶端。

瀏覽器在第一次請求發生後,再次傳送請求時:

  • 瀏覽器請求某一資源時,會先獲取該資源快取的 header 資訊,然後根據 header 中的 Cache-Control 和 Expires 來判斷是否過期。若沒過期則直接從快取中獲取資源資訊,包括快取的 header 的資訊,所以此次請求不會與伺服器進行通訊。這裡判斷是否過期,則是強快取相關。

  • 如果顯示已過期,瀏覽器會向伺服器端傳送請求,這個請求會攜帶第一次請求返回的有關快取的 header 欄位資訊,比如客戶端會通過 If-None-Match 頭將先前伺服器端傳送過來的 Etag 傳送給伺服器,服務會對比這個客戶端發過來的 Etag 是否與伺服器的相同,若相同,就將 If-None-Match 的值設為 false,返回狀態 304,客戶端繼續使用本地快取,不解析伺服器端發回來的資料,若不相同就將 If-None-Match 的值設為 true,返回狀態為 200,客戶端重新請求伺服器端返回的資料;客戶端還會通過 If-Modified-Since 頭將先前伺服器端發過來的最後修改時間戳傳送給伺服器,伺服器端通過這個時間戳判斷客戶端的頁面是否是最新的,如果不是最新的,則返回最新的內容,如果是最新的,則返回 304,客戶端繼續使用本地快取。

強快取 Expires 和 Cache-Control 的使用

強快取是利用 http 頭中的 Expires 和 Cache-Control 兩個欄位來控制的,用來表示資源的快取時間。強快取中,普通重新整理會忽略它,但不會清除它,需要強制重新整理。瀏覽器強制重新整理,請求會帶上Cache-Control:no-cachePragma:no-cache

Expires

Expires 的值是一個絕對時間的 GMT 格式的時間字串。比如 Expires 值是:expires:Fri, 14 Apr 2017 10:47:02 GMT。這個時間代表這這個資源的失效時間,只要傳送請求時間是在 Expires 之前,那麼本地快取始終有效,則在快取中讀取資料。

缺點:
由於失效的時間是一個絕對時間,所以當伺服器與客戶端時間偏差較大時,誤差很大,就會導致快取混亂。

Cache-Control

Cache-Control 主要是利用該欄位的max-age值來進行判斷,它是一個相對時間,例如Cache-Control:max-age=3600,代表著資源的有效期是 3600 秒。

cache-control 除了該欄位外,還有下面幾個比較常用的設定值:

  • no-cache:不使用本地快取。需要使用快取協商,先與伺服器確認返回的響應是否被更改,如果之前的響應中存在 ETag,那麼請求的時候會與服務端驗證,如果資源未被更改,則可以避免重新下載。

  • no-store:直接禁止瀏覽器快取資料,每次使用者請求該資源,都會向伺服器傳送一個請求,每次都會下載完整的資源。

  • public:可以被所有的使用者快取,包括終端使用者和 CDN 等中間代理伺服器。

  • private:只能被終端使用者的瀏覽器快取,不允許 CDN 等中繼快取伺服器對其快取。

Cache-Control 與 Expires 可以在服務端配置同時啟用,同時啟用的時候 Cache-Control 優先順序高。如:

cache-control:max-age=691200

expires:Fri, 15 May 2020 10:47:02 GMT

那麼表示資源可以被快取的最長時間為 691200 秒。

協商快取

協商快取就是由伺服器來確定快取資源是否可用,所以客戶端與伺服器端要通過某種標識來進行通訊,從而讓伺服器判斷請求資源是否可以快取訪問。

Etag 和 If-None-Match

Etag/If-None-Match返回的是一個校驗碼。Etag可以保證每一個資源是唯一的,資源變化都會導致Etag變化。伺服器根據瀏覽器傳送的If-None-Match值來判斷是否命中快取。

Last-Modified不一樣的是,當伺服器返回 304 (Not Modified) 的響應時,由於Etag重新生成過,response header 中還會把這個Etag返回,即使這個Etag跟之前的沒有變化。

Last-Modify / If-Modify-Since

瀏覽器第一次請求一個資源的時候,伺服器返回的header中會加上Last-Modify,Last-Modify是一個時間標識該資源的最後修改時間,例如Last-Modify: Thu,31 Dec 2037 23:59:59 GMT。當瀏覽器再次請求該資源時,request的請求頭中會包含If-Modify-Since,該值為快取之前返回Last-Modify。伺服器收到If-Modify-Since後,根據資源的最後修改時間判斷是否命中快取。如果命中快取,則返回304,並且不會返回資源內容,並且不會返回Last-Modify。

為什麼要有 Etag

兩個都可以確定快取資源的是否可用,有什麼區別呢?

Etag的出現主要是為了解決幾個Last-Modified比較難解決的問題:

  1. 一些檔案也許會週期性的更改,但是他的內容並不改變(僅僅改變的修改時間),這個時候我們並不希望客戶端認為這個檔案被修改了,而重新 GET;

  2. 某些檔案修改非常頻繁,比如在秒以下的時間內進行修改,(比方說 1s 內修改了 N 次),If-Modified-Since能檢查到的力度是秒級的,這種修改無法判斷;

  3. 某些伺服器不能精確的得到檔案的最後修改時間。

Last-ModifiedETag是可以一起使用的,伺服器會優先驗證ETag,一致的情況下,才會繼續比對Last-Modified,最後才決定是否返回 304。

程序與執行緒的區別

官網定義:

程序是系統進行資源分配和排程的基本單位

執行緒是作業系統能夠進行運算排程的最小單位

簡單理解:

程序:指在系統中正在執行的一個應用程式;程式一旦執行就是程序;程序——資源分配的最小單位。

執行緒:系統分配處理器時間資源的基本單元,或者說程序之內獨立執行的一個單元執行流。執行緒——程式執行的最小單位。

藉助阮一峰老師的解釋

1.計算機的核心是CPU,它承擔了所有的計算任務。它就像一座工廠,時刻在執行。

2.假定工廠的電力有限,一次只能供給一個車間使用。也就是說,一個車間開工的時候,其他車間都必須停工。背後的含義就是,單個CPU一次只能執行一個任務。

3.程序就好比工廠的車間,它代表CPU所能處理的單個任務。任一時刻,CPU總是執行一個程序,其他程序處於非執行狀態。

4.一個車間裡,可以有很多工人。他們協同完成一個任務。

5.執行緒就好比車間裡的工人。一個程序可以包括多個執行緒。

6.車間的空間是工人們共享的,比如許多房間是每個工人都可以進出的。這象徵一個程序的記憶體空間是共享的,每個執行緒都可以使用這些共享記憶體。

7.可是,每間房間的大小不同,有些房間最多隻能容納一個人,比如廁所。裡面有人的時候,其他人就不能進去了。

這代表一個執行緒使用某些共享記憶體時,其他執行緒必須等它結束,才能使用這一塊記憶體。

8.一個防止他人進入的簡單方法,就是門口加一把鎖。先到的人鎖上門,後到的人看到上鎖,就在門口排隊,等鎖開啟再進去。

這就叫"互斥鎖"(Mutual exclusion,縮寫 Mutex),防止多個執行緒同時讀寫某一塊記憶體區域。

9.還有些房間,可以同時容納n個人,比如廚房。也就是說,如果人數大於n,多出來的人只能在外面等著。這好比某些記憶體區域,只能供給固定數目的執行緒使用。

10.這時的解決方法,就是在門口掛n把鑰匙。進去的人就取一把鑰匙,出來時再把鑰匙掛回原處。後到的人發現鑰匙架空了,就知道必須在門口排隊等著了。

這種做法叫做"訊號量"(Semaphore),用來保證多個執行緒不會互相沖突。

作業系統的設計,因此可以歸結為三點:

(1)以多程序形式,允許多個任務同時執行;

(2)以多執行緒形式,允許單個任務分成不同的部分執行;

(3)提供協調機制,一方面防止程序之間和執行緒之間產生衝突,另一方面允許程序之間和執行緒之間共享資源。

更文不易,點個“在看”支援一下?