計算機網絡
網絡七層架構
OSI模型: 七層
TCP/IP模型: 應用層,傳輸層,網絡層,資料鍊路層,實體層 五層
層 | 簡述 |
---|---|
實體層 | 将上層資訊編碼成電流脈沖信号用于網上傳輸,不處理錯誤 |
資料鍊路層 | 确定網絡資料包的形式,加入了實體編碼,網絡拓撲,錯誤校驗,流量控制等特征 |
網絡層 | 源和終點之間建立連結,需要路由确定計算機位置,IP協定 |
傳輸層 | 向高層提供端對端的網絡資料流服務,端口-端口,TCP/UDP協定 |
會話層 | 建立、管理和終止表示層與實體之間的通信會話,建立一個連接配接 |
表示層 | 用于應用層資料編碼和轉化,確定一個系統應用層發送的資訊,可以被另一個系統應用層識别 |
應用層 | 規定資料的傳輸協定:HTTP-80/HTTPS-443 |
TCP與UDP
TCP/IP原理
TCP:Transmission Control Protocol,傳輸控制協定,面向連接配接,安全可靠的運輸層協定
UDP:User Data Protocol,使用者資料報協定,不建立連接配接,可以一對多,盡最大努力傳遞,不保證。比如ping指令測試
差別:
TCP | UDP |
---|---|
基于連接配接 | 無連接配接 |
要求系統資源多 | 少 |
結構複雜 | 結構簡單 |
流模式 | 資料報模式,多為短消息 |
保證資料正确性,可靠 | 可能丢包,不可靠 |
保證資料順序 | 不保證 |
TCP和UDP的使用場景
如何讓UDP實作可靠傳輸
TCP建立連接配接: 三次握手【阿裡,位元組】
TCP封包首部
- 源端口和目的端口
- 序号Sequence:TCP傳輸的字元流中每個位元組按順序标号,保證有序
- 确認号ack: 下一個期望收到的封包第一個位元組序号
- 确認ACK: 僅當ACK=1時,确認号字段才有效,規定當建立連接配接後所有封包傳輸ACK=1
- 同步SYN: 建立連接配接時同步序号,當SYN=1,ACK=0表明連接配接請求封包,若對方同意,則響應封包SYN=1,ACK=1
- 終止FIN: 釋放連接配接,FIN=1表示封包發送方資料發送完畢,要求釋放
三次握手過程
目的:使資料包的發送和接受同步
特點: SYN同步位隻有在TCP連接配接時才置1,連接配接成功後置0
四次揮手過程【阿裡】
資料傳輸完畢後,雙方都可釋放連接配接。最開始的時候,用戶端和伺服器都是處于ESTABLISHED狀态,然後用戶端主動關閉,伺服器被動關閉。
Q1: TCP連接配接的特點,如何保證連接配接的安全可靠【阿裡4】
TCP是面向連接配接的安全可靠的傳輸層協定。
TCP的安全可靠是通過确認重傳機制實作的,在滑動視窗協定中,接收視窗會在連續收到的包序列中的最後一個包向接收端發送一個ACK,當網絡擁堵的時候,發送端的資料包和接收端的ACK包都有可能丢失。TCP為了保證資料可靠傳輸,就規定在重傳的“時間片”到了以後,如果還沒有收到對方的ACK,就重發此包,以避免陷入無限等待中。
Q2:為什麼建立TCP連接配接需要三次握手,兩次不可以嗎?為什麼用戶端還要發一次确認呢
兩次不可以,一是為了初始化Sequence的初始值,sequence值辨別的是兩端傳輸的封包的序号,保證其不會亂序。
二主要防止已經失效的連接配接請求封包突然又傳送到了伺服器,進而産生錯誤。
如果使用的是兩次握手建立連接配接,假設有這樣一種場景,用戶端發送了第一個請求連接配接并且沒有丢失,隻是因為在網絡結點中滞留的時間太長了,由于TCP的用戶端遲遲沒有收到确認封包,以為伺服器沒有收到,此時重新向伺服器發送這條封包,此後用戶端和伺服器經過兩次握手完成連接配接,傳輸資料,然後關閉連接配接。此時此前滞留的那一次請求連接配接,網絡通暢了到達了伺服器,這個封包本該是失效的,但是,兩次握手的機制将會讓用戶端和伺服器再次建立連接配接,這将導緻不必要的錯誤和資源的浪費。
如果采用的是三次握手,就算是那一次失效的封包傳送過來了,服務端接受到了那條失效封包并且回複了确認封包,但是用戶端不會再次發出确認。由于伺服器收不到确認,就知道用戶端并沒有請求連接配接。
Q3:如果已經建立了連接配接,但是用戶端突然出現故障了怎麼辦?
TCP設有一個保活計時器,顯然,用戶端如果出現故障,伺服器不能一直等下去,白白浪費資源。伺服器每收到一次用戶端的請求後都會重新複位這個計時器,時間通常是設定為2小時,若兩小時還沒有收到用戶端的任何資料,伺服器就會發送一個探測封包段,以後每隔75秒發送一次。若一連發送10個探測封包仍然沒反應,伺服器就認為用戶端出了故障,接着就關閉連接配接
Q4:為什麼用戶端最後還要等待2MSL?
MSL(Maximum Segment Lifetime)
第一,保證用戶端發送的最後一個ACK封包能夠到達伺服器, 因為這個ACK封包可能丢失,站在伺服器的角度看來,我已經發送了FIN+ACK封包請求斷開了,用戶端還沒有給我回應,應該是我發送的請求斷開封包它沒有收到,于是伺服器又會重新發送一次,而用戶端就能在這個2MSL時間段内收到這個重傳的封包,接着給出回應封包,并且會重新開機2MSL計時器。
第二,防止類似與“三次握手”中提到了的“已經失效的連接配接請求封包段”出現在本連接配接中。用戶端發送完最後一個确認封包後,在這個2MSL時間中,就可以使本連接配接持續的時間内所産生的所有封包段都從網絡中消失。這樣新的連接配接中不會出現舊連接配接的請求封包。
Q5:為什麼建立連接配接是三次握手,關閉連接配接确是四次揮手呢?
建立連接配接的時候, 伺服器在LISTEN狀态下,收到建立連接配接請求的SYN封包後,把ACK和SYN放在一個封包裡發送給用戶端。
而關閉連接配接時,伺服器收到對方的FIN封包時,僅僅表示對方不再發送資料了但是還能接收資料,而自己也未必全部資料都發送給對方了,是以伺服器可以立即關閉,也可以發送一些資料給對方後,再發送FIN封包給對方來表示同意現在關閉連接配接,是以,伺服器ACK和FIN一般都會分開發送,進而導緻多了一次。
Http原理
http:超文本傳輸協定,是一個基于請求-響應協定,無狀态的,應用層協定,基于TCP/IP協定傳輸資料,定義web Brower和server之間交換資料的通訊格式
- 請求-響應:用戶端請求,服務端響應
- 無狀态: 斷開之後不儲存彼此資訊,下次重建立立連接配接(改進:cookie)
HTTP請求封包
請求封包包括:請求行,多個資訊頭(請求頭),請求體(實體内容)
- 請求行:用戶端請求方式Get/Post, 請求資源名稱(URL位址),和封包的Hosts屬性組成完整的請求URL,使用的HTTP版本号
- 請求方式:Get,Post,Delete,Head,Option
- 請求頭(Header) :HTTP的封包頭,包括若幹個屬性(屬性名:屬性值),用來描述用戶端的資訊:請求那個主機以及用戶端的環境資訊,與緩存相關的規則資訊等,伺服器根據封包頭擷取用戶端資訊
- Accept:用戶端 接收的響應類型(文本,圖檔,視訊,音頻等)
- Accept-language,Accept-Encoding:用戶端接收的語言類型以及編碼方式:支援什麼壓縮
- Host:請求資源的主機和端口号,從URL中提取
- User-Agent:用戶端使用的作業系統和浏覽器版本和名稱
- Connection:Keep-alive表示網頁打開完成後,用于傳輸Http的TCP連接配接不會關閉,Close:請求完成後關閉連接配接
- Referer:上文伺服器,告訴伺服器是從哪個伺服器跳轉過來的
- cookie:傳用戶端的Cookie給伺服器端,讓伺服器知道請求是屬于哪個會話
- Cache-Control:控制緩存,比如一個請求希望響應傳回的内容在用戶端的緩存機制:public,private,no-cathe
- If-Modify-Since:浏覽器記錄的緩存頁面最後修改時間,發送給伺服器和伺服器檔案的實際最後修改時間進行比對,一緻傳回304,用戶端使用本地緩存頁面,不一緻傳回200和新的檔案内容。用戶端收到丢棄舊檔案,儲存新檔案,斷點續傳
- If-None-Match:和ETag字段一起工作,當使用者再一次請求某個資源時,在Http請求中加入If-None-Match資訊,放入ETag的值,如果伺服器驗證資源ETag 沒改變,說明資源沒更新,就傳回304告訴用戶端使用本地緩存檔案,否則發送200和新的資源以及Etag,來提高網站性能
- 請求體:封包體,包含多個請求參數,比如Post請求中的資料
HTTP響應封包
響應封包包括:狀态行,響應頭,實體内容
- 狀态行: Http協定版本号,狀态碼,狀态消息組成,用來描述伺服器對請求的處理結果
- 響應頭: 描述伺服器基本資訊,以及對資料的描述,告訴用戶端如何處理它回傳的資料
- Cache-control: 告訴用戶端如何控制響應内容的緩存:private,public,no-cache
- ETag: 通路資源的标記,如果伺服器端資源發生改變,ETag值也會變化,與用戶端的If-None-Match一起工作,決定用戶端什麼時候從緩存中取資源,什麼時候從伺服器端回新的資源
- Last-Modified: 訓示資源最後修改時間
- Location: 重定向的資源URL
- Set-Cookie: 設定用戶端的Cookie
- 響應對象類型,實體長度,壓縮方式等
- 實體内容: 回傳的資料
HTTP請求方法【阿裡1】
請求方式:POST,GET(預設),HEAD,OPTIONS,DELETE等,可通過更改表單的送出方式實作修改請求方式
Put請求:如果兩個請求相同,後一個請求會把第一個請求覆寫掉。(用來改資源)
Post請求:後一個請求不會把第一個請求覆寫掉。(是以Post用來增資源)
Get請求: 在請求的URL後以?帶上上交給Server的資料,資料間以&分隔
Get和Post差別:
- GET參數通過URL明文傳遞,不安全. POST放在Request body中。
- GET請求會被浏覽器主動cache,而POST不會,除非手動設定。
- GET請求參數會被完整保留在浏覽器曆史記錄裡,而POST中的參數不會被保留。
- Get 請求中有非 ASCII字元,會在請求之前進行轉碼,POST不用,因為POST在Request body中,通過 MIME,也就可以傳輸非 ASCII 字元。
- 一般我們在浏覽器輸入一個網址通路網站都是GET請求
Cookie和Session差別
HTTP狀态碼【阿裡2】
狀态碼 | 說明 |
---|---|
200 | 響應成功 |
302 | 重定向,跳轉位址通過響應頭的Location指向 |
304 | Not Modified:上次文檔已緩存,還可以使用 |
400 | 用戶端請求有文法錯誤,伺服器不能識别 |
403 | 伺服器收到請求,拒絕提供服務(認證失敗) |
404 | 請求資源不存在 |
500 | 伺服器内部錯誤 |
HTTP傳輸過程【位元組1】
先通過三次握手建立TCP連接配接,用戶端向伺服器端發送HTTP請求,伺服器端查找資源後發出HTTP響應,資料傳輸完成後TCP四次揮手斷開連接配接
HTTP1.0 、1.1 、2.0差別[位元組1]
- HTTP1.0:Client和server連接配接後隻能獲得一個web資源,不支援斷點續傳
- HTTP1.1:在一個連接配接上擷取多個web資源,可以傳送多個HTTP響應和請求,支援持久化連接配接,斷點續傳,引入更多緩存政策,FIFO處理請求-響應
- HTTP2.0:進行了二進制分幀,封裝了HTTP消息,這些幀對應着邏輯流中的消息,很多流可以并行地在同一個TCP連接配接上交換消息,支援多向請求與響應:用戶端和伺服器可以把HTTP消息分解為互不依賴的幀,然後亂序發送,最後再在另一端把它們重新組合起來。
1.0與1.1差別:
- 帶寬優化及網絡連接配接的使用,HTTP1.0中,存在一些浪費帶寬的現象,例如用戶端隻是需要某個對象的一部分,而伺服器卻将整個對象送過來了,并且不支援斷點續傳功能,HTTP1.1則在請求頭引入了range頭域,允許隻請求資源的某個部分
- Host頭處理,在HTTP1.0中認為每台伺服器都綁定一個唯一的IP位址,是以,請求消息中的URL并沒有傳遞主機名(hostname)。但随着虛拟主機技術的發展,在一台實體伺服器上可以存在多個虛拟主機(Multi-homed Web Servers),并且它們共享一個IP位址。HTTP1.1的請求消息和響應消息都應支援Host頭域,且請求消息中如果沒有Host頭域會報告一個錯誤(400 Bad Request)。
- 長連接配接,HTTP 1.1支援長連接配接(PersistentConnection)和請求的流水線(Pipelining)處理,在一個TCP連接配接上可以傳送多個HTTP請求和響應,減少了建立和關閉連接配接的消耗和延遲,在HTTP1.1中預設開啟Connection: keep-alive,一定程度上彌補了HTTP1.0每次請求都要建立連接配接的缺點。
HTTP 和HTTPS的差別
HTTPS:更加安全
- HTTP協定運作在TCP之上,所有傳輸的内容都是明文,HTTPS運作在SSL/TLS之上,SSL/TLS運作在TCP之上,所有傳輸的内容都經過加密的
- HTTP和HTTPS使用的是完全不同的連接配接方式,用的端口也不一樣,前者是80,後者是443
- HTTPS有效防止營運商劫持
HTTP斷點續傳【位元組1】
http1.1協定支援擷取檔案的部分内容,為并行下載下傳和斷點續傳提供了技術支援,通過在Header 裡兩個參數實作的,用戶端發請求時對應的是 Range ,伺服器端響應時對應的是 Content-Range
增強校驗
發起續傳請求時,所對應的檔案内容變化,此時需要定義一個标記檔案唯一性的方法,伺服器端用Last-Modified 來辨別檔案的最後修改時間,同時還定義一個 ETag 頭,可以使用 ETag 頭來放置檔案的唯一辨別(标記檔案是否被修改)。
用戶端在發起續傳請求時在HTTP頭中申明If-Match 或者If-Modified-Since 字段,幫助服務端判别檔案變化。
HTTP還定義有一個If-Range頭,終端如果在續傳是使用If-Range。If-Range中的内容可以為最初收到的ETag頭或者是Last-Modfied中的最後修改時候。服務端在收到續傳請求時,通過If-Range中的内容進行校驗,校驗一緻時傳回206的續傳回應,不一緻時服務端則傳回200回應,回應的内容為新的檔案的全部資料。
DNS域名解析【位元組1】
産生原因
DNS是應用層協定:網絡通信使用TCP/IP,基于IP位址,隻能識别ip位址,不認識域名,是以通過DNS伺服器解析域名,DNS包括域名解析器和域名伺服器
DNS過程
- 用戶端運作DNS用戶端,當通路URL時,浏覽器将域名抽出來發給DNS用戶端
- DNS用戶端(也就是DNS解析器)向DNS伺服器端發起查詢封包(UDP),收到回答封包裡包含主機名對應的IP位址
- 浏覽器用IP位址定位的HTTP伺服器發起TCP連接配接
DNS伺服器為什麼使用分布式
集中式簡單,但會出現單點故障,有延遲,維護開銷大,是以使用分布式的層次資料庫模式以及緩存方法來解決單點集中式的問題。
DNS伺服器層次結構
13個根DNS伺服器,頂級DNS伺服器,權威DNS伺服器
為什麼DNS用UDP傳輸?
- 一次UDP交換可以短到兩個包:一個查詢包、一個響應包。一次TCP交換則至少包含9個包:三次握手初始化TCP會話、一個查詢包、一個響應包以及四次分手的包交換。
- 效率:TCP連接配接的開銷大,故采用UDP作為DNS的運輸層協定,這也将導緻隻有13個根域名伺服器的結果。
URL網址加載過程
DNS解析->TCP連接配接->HTTP請求-響應–>url浏覽器渲染
Socket通信過程
兩個主機的程式之間通過套接字進行通信
https://zhuanlan.zhihu.com/p/29814861
https://blog.csdn.net/HEYUTAO007/article/details/6588302
- Socket是對TCP/IP協定族的封裝,是應用層和TCP/IP協定族通訊的中間軟體抽象層,把複雜的TCP/IP隐藏在Socket接口後面,使用者通過簡單的調用socket接口讓socket組織資料,已符合指定的協定
- Socket還是一種網絡間不同計算機上程序通訊的方法,網絡中使用三元組**[ip位址,協定,端口]**唯一辨別網絡的程序,(本地使用PID辨別程序 )程序通信使用這個标志和其他程序通信
ARP在哪一層
擁塞控制和快重傳
滑動視窗
UDP和TCP差別,怎麼讓UDP實作可靠連接配接
CDN
端口
TCP/IP協定中的端口含義
TCP/IP協定族中的主要端口号
測試端口聯通的方法
Http常用指令
- wget: wget從網絡下載下傳資源, 支援HTTP,HTTPS和FTP協定
- telnet:不安全的協定,可以測試連接配接有效性
- ssh: 連接配接遠端伺服器
- curl: 是一個使用URL文法來傳輸資料的工具。比Telnet強大的點是:cURL可以建立HTTP Request(即可以指定GET, POST, HEAD等方法)
curl -l --request GET www.nowcoder/discuss/879/資源
HTTP禁用緩存操作
response.setHeader("Pragma", "no-cache");
response.setDateHeader("Expires", 0);
response.setHeader("Cache-Control", "no-cache,no-store");
HTTP1.0和HTTP1.1和HTTP2.0的差別
TCD、UDP差別及應用場景
作業系統
并發和并行差別
并行(parallel):指在同一時刻,有多條指令在多個處理器上同時執行。是以無論從微觀還是從宏觀來看,二者都是一起執行的。
**并發(concurrency):**指在同一時刻隻能有一條指令執行,但多個程序指令被快速的輪換執行,使得在宏觀上具有多個程序同時執行的效果,但在微觀上并不是同時執行的,隻是把時間分成若幹段,使多個程序快速交替的執行。
程序和程式的差別
程式:由若幹條具有一定功能的指令所組成的解題順序和步驟, 靜态的,沒有生命周期
程序:程式的一次動态執行過程,是作業系統進行資源配置設定和保護的基本機關, 有生命周期, 比如:就緒态,運作态,阻塞态. 程序是一種資料結構,目的在于有效排程和管理進入計算機主存運作的程式
- 一個程式可以對應多個程序,但是一個程序隻能對應一個程式;
- 程序是一個能夠獨立運作的機關,可以和其他程序并發執行
線程,程序,協程的了解
協程和子例程一樣,是一種程式元件,更加一般和靈活.
一個程式可以包含多個協程,可以對比與一個程序包含多個線程,
協程和線程差別: 多個線程相對獨立,有自己的上下文,切換受系統控制;而協程也相對獨立,有自己的上下文,但是其切換由自己控制,由目前協程切換到其他協程由目前協程來控制。
協程和線程差別:協程避免了無意義的排程,由此可以提高性能,但也是以,程式員必須自己承擔排程的責任,同時,協程也失去了标準線程使用多CPU的能力。