網絡課程知識 問題

內網是如何做到的?

答:內網是指局域網內的網絡可以相互訪問的概念。內網開啟一個服務器假丧,因其IP是私網IP, 如果不是在同一網絡下动羽,是找不到該服務器的MAC 地址的包帚。只有鏈接到相同網段的網絡, 利用ARP廣播才能找到 改服務器的mac地址运吓。

后臺布置的開發(fā)服務器 和我們自己電腦開的 sever 有啥區(qū)別渴邦? 后臺布置的開發(fā)服務器 是私網IP嗎? 自己的sever 開的服務 是 私網IP拘哨。 因為 私網ip 存在 谋梭。 會導致私網ip 相同, 因為 同一網段請求 不走路由 倦青, 可以直接 arp 直連尋mac地址瓮床。 那我是不是 內網的接口 到別人家公司 也能請求到? (很荒謬的問題姨夹, 但是 就是想知道 存在這種可能性 對吧纤垂?)。

答:后臺布置的開發(fā)服務器一般都是放在自己公司內網的私有IP 上磷账。跟我們自己的電腦開啟的服務器是一樣的峭沦。確實是 可能會出現(xiàn)烏龍現(xiàn)象。

NAT PNT.

答: 因局域網的IP 是私有IP 為解決ip地址不夠用問題逃糟。所有的私有IP電腦想訪問互聯(lián)網需要再路由器進行 公網IP轉換吼鱼。這個轉換稱之為 NAT。

公網ip 私網ip

答:如果 世界上所有的IP 地址 都是唯一的绰咽, 每一臺主機分配一個獨一無二的IP 菇肃。那么IP 地址是不夠用的,為解決 IP 不夠用的的問題取募, 局域網的IP 都是重復的琐谤, 有幾個號段 被分為局域網IP。

路由間ARP 是采用動態(tài)路由 方式 找到鏈接路徑玩敏。 然后 在最后的 路由 發(fā)送ARP 尋mac地址斗忌。

路由直接傳遞 采用ppp 協(xié)議 ppp協(xié)議 沒有包裝 源MAC地址 和 目標mac地址。 那傳過去的 數(shù)據(jù) 到最后的 的時候 如何 找到 私有mac 地址呢旺聚? arp 協(xié)議的時候 傳遞了嗎织阳?

TCP 擁塞控制。 流量控制砰粹。

http1.0, 1.1, http2.0的區(qū)別唧躲?

答:http1.0 超文本傳輸協(xié)議。無狀態(tài):服務器不跟蹤不記錄請求過的狀態(tài) ,無連接:瀏覽器每次請求都需要建立tcp連接弄痹,發(fā)送請求 三次握手 饭入,四次分手,客戶端主動鏈接服務端肛真,每次發(fā)送http請求 都必須 建立一次新的TCP鏈接圣拄。
http 1.1 :長連接。持請求管道化(pipelining)毁欣。此外,HTTP/1.1還加入了緩存處理 新的字段如cache-control岳掐,支持斷點傳輸 range凭疮,以及增加了Host字段(使得一個服務器能夠用來創(chuàng)建多個Web站點)。
可以做到 建立一次TCP連接串述,發(fā)送多次http請求执解。 缺點是 http請求 是同步的, 必須一次 請求完畢纲酗,再發(fā)另外一個衰腌。瀏覽器 如果想實現(xiàn)并發(fā)請求,就是建立多個并發(fā)連接觅赊。瀏覽器 最多針對同一個域名 六個鏈接右蕊。請求應答模式,只能客戶端主動發(fā)起請求吮螺。(同一次會話) 每次TCP鏈接完成之后 發(fā)送多次HTTP 請求都攜帶重復的 請求頭信息饶囚。(同一次會話 是指 http1.1 的建立一個tcp 鏈接發(fā)送多個http請求,是建立在相同 域名情況下的 http請求鸠补。 如果不是一個域名的 不能一起)萝风;
SPDY http2.0 前身, http應用層 構造數(shù)據(jù)完畢后 發(fā)送到 SPDY層 在發(fā)送給TCP 層紫岩。
http2.0 采用二進制格式傳輸數(shù)據(jù)规惰,把 header 和body 數(shù)據(jù)部分 拆成兩個二進制流。將header 和body打散泉蝌。
http2.0 多路復用歇万。 請求 利用一個tcp 通道。 發(fā)送多個http請求梨与, 每個http 請求也被分成多個幀堕花,可以并發(fā)的 出現(xiàn)在發(fā)送鏈路上。 (不管是 http 1.1 還是http2.0 的 一個tcp 通道 里面?zhèn)鬏數(shù)膆ttp 請求 都只能是 一個域名下的粥鞋,也就是可以理解為 http 請求的TCP 通道 是建立在同一域名下的缘挽。)
http 2.0 優(yōu)先級。
http 2.0 頭部壓縮 ,HPACK算法技術壕曼,實現(xiàn)頭部信息壓縮苏研。http2.0 http報文多幀交錯發(fā)送, 后面發(fā)送的 可以 標識 我跟上次發(fā)送的 頭部信息比較 差異點 發(fā)送腮郊, 不需要攜帶 相同的信息摹蘑。
http 2.0 服務器推送,服務器對客戶端一次請求 多次響應轧飞。
http 2.0 隊頭堵塞問題衅鹿。 采用TCP協(xié)議。 需要確保數(shù)據(jù)安全性过咬,數(shù)據(jù)發(fā)送之后 需要確保 本次發(fā)送成功 才會繼續(xù)發(fā)送下一個段大渤,盡管http2.0 會將http 包分成 多個報文發(fā)送給TCP。但是TCP 在發(fā)送這些數(shù)據(jù)的時候 還是要求確保 之前傳遞過去的 重傳成功 才會 處理后面?zhèn)鬟f的掸绞。這是TCP在報文傳遞失敗 需要保證重傳技術導致的泵三,不是http 2.0的問題。
后采用QUIC 協(xié)議 可以解決這個問題衔掸。 QUIC協(xié)議 采用的是 UDP傳輸層協(xié)議烫幕。
QUIC 協(xié)議 就是 http3.0采用的技術。 更新了 HPACK算法 壓縮header 信息改變?yōu)?QPACK算法敞映。TCP協(xié)議更換為UDP協(xié)議
UDP 不靠譜 较曼,由QUIC協(xié)議保證 可靠性。
Http2.0 握手延遲問題驱显。
HTTP3.0 特性诗芜, 鏈接遷移,網路由4G切換到WiFi 原HTTP 是會鏈接超時埃疫,在重新建立連接的伏恐。會出現(xiàn)網絡錯誤的提示。 HTTP3.0 的QUIC協(xié)議 是利用UDP 協(xié)議的 栓霜, 采用一組connect id 記錄的 鏈接翠桦, 只要id 不變化, 就會維持鏈接不斷開胳蛮。

基于HTTP 1.1 和 2.0 可以優(yōu)化網絡的 方案销凑。
影響一個網絡請求的因素主要有兩個,帶寬和延遲

  1. http 1.1 TCP 通道上請求是同步的仅炊,可以多開幾個TCP 鏈接 斗幼。發(fā)起并行請求。(手機端 是不是的http 層 在 framework 里面 他會開幾個tcp 鏈接 不知道抚垄。但是可以確定的是 域名不同絕對不是一個通道)
  2. 減少請求數(shù)量蜕窿,web端 指合并多個CSS/js 文件谋逻,或者講CSS/js文件內置到html里面, 手機客戶端優(yōu)化方向是 減少 頁面請求數(shù)量桐经,合并多個請求為一個接口毁兆。(針對http1.1的優(yōu)化)。
  3. 小圖片 采用 base64編碼圖片 來解決 url 向服務器請求圖片的過程阴挣。
  4. 其他列表頁面 多圖片頁面气堕,采用 圖片 多個域名方式,開啟多個TCP通道 請求方式畔咧。

手機客戶端 http 請求 問題

問題1: http 1.1 請求 瀏覽器 針對同一域名 最多是開六條TCP連接 去發(fā)起請求茎芭, 那么蘋果手機呢? 最多開幾個TCP http連接?誓沸。(ios 可能是 根據(jù) 你開的線程 開一條線程 是一個TCP 鏈接骗爆。也能使 nsurlsession 設置的 連接池)(如果這樣 AFN 每一個對象是不是就是一個 線程。那 如何控制最大線程數(shù)呢蔽介?)

問題2: HTTP 的json 請求和form 表單請求的區(qū)別。 報文層面的區(qū)別煮寡。

答:json請求和from 表單請求 是指http 超本文傳輸協(xié)議的報文的 data 數(shù)據(jù)行的封裝格式不同 from表單是 用=號鏈接的 key 和value虹蓄。 json請求是 數(shù)據(jù)行是 json字符串。

問題3: https 和 tcp 順序

答: 看似上下層 其實類似 你如果采用Httt協(xié)議幸撕。 TCP 會先三次握手薇组。第一次握手交換一些信息。

問題4: 客戶端 如何選擇 是使用http 1.1 還是 http 2.0 坐儿。

答: 是ALPN 協(xié)議律胀, 是在TLS交互的時候 服務端 告知 客戶端 服務器是 什么版本 的請求。(https 有tls 協(xié)議貌矿。 http 沒有用這個協(xié)議啊?)

TCP 傳遞數(shù)據(jù) 過大炭菌, 是TCP 分段 還是 傳遞到 數(shù)據(jù)鏈路層 再分?

答: http 1.0逛漫、1.1 版本 都是TCP 會先分段發(fā)送黑低。2.0 版本 直接在http層 就把數(shù)據(jù)分成了幀。因為TCP 需要可靠性傳說酌毡, 擁塞控制等 需要控制包大小克握。所以在上層TCP 就分割了數(shù)據(jù)。

ANF 如何確定respose 首部

跨域知識枷踏, 客戶端如何操作跨域

服務器集群 菩暗。

抓包軟件 為什么 電腦端 不需要設置網絡代理 直接可以抓包。 2.為什么手機需要配置代理旭蠕。3.為什么手機配置代理 還需要在同一WiFi下停团。

CDN 是把靜態(tài)文件放到CND 服務器嗎旷坦? 還是緩存過去的? 為啥會有一些文件是CDN 開頭的域名客蹋? 動態(tài)數(shù)據(jù)接口呢塞蹭? 做不到這個功能啊讶坯?

答:CDN 加速 番电,是指 采用了CDN 的服務器,在用戶訪問 靜態(tài)資源的時候 辆琅,離用戶最近的CDN節(jié)點 會把 緩存 的靜態(tài)資源文件直接返回漱办,不需要在請求到根服務器,減輕服務器壓力婉烟。對于這些靜態(tài)資源 更新問題 這里暫且不表娩井,總之他會有自己的請求頭設置文件過期的傅物。 針對 post get put 等接口請求的 無法做到加速休弃。 還有一種 直接把靜態(tài)文件放到CND 服務器上去传蹈,這種就是純靜態(tài)資源文件了革答。 一般第三方或者是靜態(tài)開源庫的 可采用的加速下載方式昙楚。eg ios 的cocopoads 有CDN 源愁憔, 就是 下載的url 從github 切換到cdn 上去粘招。

TCP 和UDP 服務器 可以是一個端口嗎?(TCP/UDP 是傳輸層協(xié)議稿存。 服務器是針對端口進行監(jiān)聽而涉,所以一個服務器 應該是 可以既監(jiān)聽 TCP 又可以監(jiān)聽 UDP 著瓶。網絡層來了之后針對)

答: 可以。 因為在在服務器上 TCP 和UDP 在內核層面 是兩個獨立的應用程序啼县。TCP和UDP 是屬于傳輸層協(xié)議材原。 可不可以監(jiān)聽同一端口 是客戶端再發(fā)消息給服務端的時候 服務端能否區(qū)分出來 是 發(fā)給UDP還是TCP 的數(shù)據(jù),轉給發(fā)給哪個協(xié)議處理數(shù)據(jù)季眷。服務端的傳輸層數(shù)據(jù)是網絡層數(shù)據(jù)傳遞過來的余蟹。 IP協(xié)議 規(guī)定 在IP 包的首部里面 有一個位置 記錄了 傳輸層數(shù)據(jù) 采用的協(xié)議是什么。所以在ip層就能區(qū)分出是UDP還是TCP子刮。

「多個 TCP 服務進程可以綁定同一個端口嗎客叉?」

這個問題的答案是:如果兩個 TCP 服務進程同時綁定的 IP 地址和端口都相同,那么執(zhí)行 bind() 時候就會出錯话告,錯誤是“Address already in use”兼搏。但是如果

「同一個服務器可以有多個IP嗎?」

答:可以沙郭,擁有倆個網卡的機器 可以設置不同的IP佛呻。

客戶端的端口可以重復使用嗎?

答:可以的病线, 端口可以在不同IP的服務器上重用吓著。

域名可以直接映射到某個端口鲤嫡?eg:我服務器開了倆端口的監(jiān)聽的。我如何用倆域名分別直接請求到 該端口上绑莺?

加密 的加鹽 是什么意思暖眼。

代理后 cookie 如何設置 (會導致不代理后 也能帶cookie嗎?)纺裁? 保證 不失效诫肠。

mac地址和IP 都是唯一的 為什么還需要倆個東西。

答: IP地址不唯一 有私網IP 概念欺缘。 在互聯(lián)網上只有公網IP 才可以被識別栋豫。我們兩個局域網的 設備通信 其實 是利用NAT 技術 把私網IP 轉換為公網IP 發(fā)送消息。屬于網絡層谚殊。理他IP 準確找到另一端的路由丧鸯。 然后 通過路由的本地網絡之間 通過MAC地址通信。二者缺一不可嫩絮。

網絡 瑣碎知識點

基礎知識點:集線器丛肢,網橋,交換機剿干。 順序是隨著時間推移的摔踱。 目前家里的網線布置和公司網絡布置采用交換機和路由器方式。 集線器 HUB單通信相當于網線單雙工通信 (只有一個通道怨愤,發(fā)消息就不能同時接消息)。 網橋稍微有點智商蛹批,可以記錄一下要去mac 地址在他左側右側 (但是他只有倆口)也是半雙工通信 撰洗。交換機 相當于 網橋和集線器 組合, 有多個接口腐芍, 可以記錄mac地址在哪條線上差导。全雙工通信。

MAC 地址猪勇, IP地址 设褐, 子網掩碼 ,網段泣刹,子網助析,超網。

MAC 地址 6字節(jié) 數(shù)字椅您。 一臺電腦 一個mac地址外冀, 全世界唯一, 對應一個網卡掀泳。 前三字節(jié) iso 頒布 雪隧,后三個字節(jié) 廠商自制西轩。 所以發(fā)網絡 最后尋找 mac 地址 才能找到最終要發(fā)消息的電腦。 (IP 不唯一 “私網IP”的原因)
IP地址 分兩部分組成 eg:192.168.1.1 網絡ID和 主機ID 脑沿。 用點分開 四部分藕畔, 每部分站一個字節(jié)取值 0~255 。 網絡ID 和主機ID 怎么劃分這四部份庄拇,需要條件注服。
IP 根據(jù)條件 劃分為 四類。
A類網址:第一個 192 的取值范圍 在0~127 之間的 為 A類網址丛忆。 A類網址后面三個數(shù)都是 主機ID 只有第一個數(shù)是網絡ID祠汇。
B類網址:第一個 192 的取值范圍在 128~191 之間的為B類網址。B類網址后面三個數(shù)都是主機ID 前兩個是 網絡ID
C類網址:第一個數(shù) 192的取值范圍在 192~224 之間的為c類網址熄诡。C類網址 最后一個數(shù)為主機ID 前三個是 網絡ID
D類網址:~~~~~~~~~~~~
子網掩碼 : 用來求出 ip 所在網段的東西可很。 也是4字節(jié)的一段數(shù)字。一般是 255.255.255.0 這種 就是 C類網址的子網掩碼凰浮。
網段: IP & 子網掩碼 求出來的 值我抠。一般子網掩碼的主機ID部分都是0 。 所以&出來的網段 主機部分都是0. 所以根據(jù)子網掩碼很容易看出IP是哪類網址 袜茧,反推易可菜拓。(沒有子網和超網的情況)。
同一網段的計算機可以直接通信笛厦。 一個路由器后面連著的計算機屬于同一網段纳鼎。
主機ID: 就是某一個網段下 可以放的最大計算機數(shù)量。
子網:讓一個ip 可以擁有更多 計算機裳凸。往主機ID 移動一個子網掩碼贱鄙。
超網:讓一個ip 可以減少計算機數(shù)量。 往網絡ID 移動以為子網掩碼姨谷。
相反的操作逗宁。 同一個網段, IP和子網掩碼的變化 梦湘, 讓主機ID 變多變少的操作瞎颗。

公網IP 私網IP

公網IP 唯一。
私網IP 不唯一捌议,局域網設置的IP哼拔。大家的路由器直連 一般都是192.168.1.1 就是路由器的 ip。都一樣 192.168.0.0~192.168.255.255 之間都是 私網IP瓣颅。

NAT

私網IP轉換公網IP.在請求的時候 在路由器的時候會把 私網IP 轉換為 公網IP管挟。

分層: 物理層->數(shù)據(jù)鏈路層->網絡層->傳輸層->應用層

物理層:指的是 我們真實生活中物品 eg:網線,路由 弄捕,交換機僻孝,集線器等导帝。規(guī)定了 接口定義 線纜標準,傳輸速率等穿铆。
數(shù)據(jù)鏈路層: 就是我們傳輸?shù)木W絡數(shù)據(jù) 經過路由器 交換機 主機 之間的鏈路您单。常用的有 路由器和路由器直連的鏈路 采用的是ppp協(xié)議封裝數(shù)據(jù)。 路由器和主機荞雏,路由器和交換機 虐秦,交換機和主機之間的鏈路是采用CSMA/CD 協(xié)議傳輸數(shù)據(jù)。以太網 2.0協(xié)議凤优。 (這里協(xié)議是指 對數(shù)據(jù)進行一層包裝(就是添加首部和尾部悦陋。后面具體介紹)然后再鏈路上傳遞 不同的協(xié)議 包裝方式不同)。
網絡層:網絡層是指 對數(shù)據(jù)進行包裝筑辨,切割為多組數(shù)據(jù)包 傳遞給下層數(shù)據(jù)鏈路層俺驶,因為傳遞給數(shù)據(jù)鏈路層的網絡層數(shù)據(jù)有最大限制 1500字節(jié) 。網絡層主要功能為 對數(shù)據(jù)進行包裝 棍辕, 切割暮现。 常用協(xié)議 ARP,IP 楚昭,ICMP 協(xié)議栖袋。
傳輸層:對運輸層數(shù)據(jù)進行包裝。網絡連接等操作抚太。 TCP UDP 協(xié)議塘幅。
應用層: 要傳輸?shù)臄?shù)據(jù)的處理。 post get 等請求方式不同 處理方式不同尿贫。 http https DNS FTP .

物理層 知識點

單工通信 :信號只能一個方向傳輸电媳。
半雙工通信:信號可以雙向傳輸, 但是 同一時間只能一個方向上有數(shù)據(jù)帅霜。
全雙工通信:信號可以雙休傳輸, 同一時間 既可以收消息 又可以發(fā)消息呼伸。

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

鏈路: 網線 一個節(jié)點到另外一個節(jié)點的物理線路稱為鏈路身冀。eg:PC和路由器之間的線路。 PC 和交換機之間的線路括享。 交換機和路由器搂根,路由器和路由器。特殊 PC和交換機铃辖,交換機連著路由器 剩愧,這兩段可以合稱為一個線路。
在每條鏈路上傳遞數(shù)據(jù) 需要特殊的通訊協(xié)議娇斩。 不同的鏈路通訊協(xié)議不同仁卷。eg CSMA/CD ,PPP協(xié)議穴翩。 CSMA/CD 協(xié)議是 集線器連接的協(xié)議。 交換機連線的類似锦积,又不同芒帕。
數(shù)據(jù)鏈路層協(xié)議 特點

封裝成幀:對IP網絡層傳遞過來的數(shù)據(jù)包 封裝成幀,添加 首部和尾部丰介。
透明傳輸:數(shù)據(jù)鏈路層 CSMA有幀開始符背蟆,幀結束符,防止網絡層數(shù)據(jù)中有幀開始符和幀結束符哮幢,對數(shù)據(jù)進行補充字符带膀。
差錯檢驗:防止數(shù)據(jù)被修改。 FCS (4字節(jié))橙垢, 幀首部計算得出的FCS 的值垛叨。驗證不通過 ,網卡不會繼續(xù)往上傳钢悲,不會傳給服務器点额。會報錯。 屬于尾部莺琳。

MUT最大傳輸單元还棱,規(guī)定網絡層傳遞過來的數(shù)據(jù)不得超過 最大傳輸單元 ,以太網傳遞最大MUT為1500字節(jié)惭等。

CSMA/CD協(xié)議
  • CSMA/CD協(xié)議封裝的數(shù)據(jù)又稱以太網幀珍手。(目前使用的是Ethement V2標準,沒有幀開始和真結束符號辞做,也就不用補充字節(jié)了琳要。透明傳輸是不是也就沒用了?)
  • 以太網幀 至少64字節(jié)秤茅。 為了能做到防止沖突稚补,知道是別人發(fā)給我的 還是我自己發(fā)送的 沖突后返回給我的數(shù)據(jù)幀。保證可以一個來回框喳。
  • 以太網幀 是對網絡層傳遞過來的數(shù)據(jù) 機型包裝课幕, 包括 首部,數(shù)據(jù)五垮,尾部FCS乍惊。 FCS占 4字節(jié)。
    • 首部包括 目標MAC地址放仗,源MAC地址润绎,網絡類型IPV4還是ipv6。首部大小為 6字節(jié)+6字節(jié)+2字節(jié) = 14字節(jié)。 類型占2字節(jié)莉撇。 又因為 以太網幀 最小為64字節(jié) 所以 要求 網絡層數(shù)據(jù)最小為 64-14 -4=46字節(jié)呢蛤。如果網絡層數(shù)據(jù)小宇46字節(jié),數(shù)據(jù)鏈路層會補充到46字節(jié)稼钩。最大是 1500 字節(jié)顾稀。所以以太網幀 范圍是 46~1518之間。
PPP協(xié)議 :點對點協(xié)議坝撑。 兩個路由器之間的數(shù)據(jù)傳遞静秆。一根網線直連的鏈路。
  • 對網絡層數(shù)據(jù)包裝 添加 首部和尾部FCS 巡李。
  • 首部 不包含 目標MAC 和源MAC抚笔。 有幀開始 和幀結束符號。

網絡層 (IP協(xié)議侨拦,ARP協(xié)議殊橙,ICMP協(xié)議 ping走的協(xié)議)

  • 網絡層包裝好的數(shù)據(jù) 稱為 包。 (以下是對IP協(xié)議進行解析狱从,其他類似膨蛮,)
  • 網絡層 大多數(shù)是對傳輸層數(shù)據(jù)進行包裝。添加首部季研。所以網絡層的數(shù)據(jù)包括兩部分 首部+ 數(shù)據(jù)敞葛。(為什么說大多數(shù)數(shù)據(jù)是從傳輸層傳遞下來的呢?是因為有些操作的數(shù)據(jù)不是從傳輸層包裝傳遞下來与涡,而是由網絡層自己構造數(shù)據(jù)的惹谐,eg:ICMP協(xié)議和ARP協(xié)議,他們還有不同驼卖。ICMP在網絡層 按照傳輸層結構構造數(shù)據(jù)氨肌。 ARP 的數(shù)據(jù)部分 跟傳輸層接的數(shù)據(jù)又不相同。具體沒深入了解)
  • 網絡層首部 分為 固定部分 20字節(jié) +可選部分(大多數(shù)沒有這部分)酌畜。
    • 網絡層首部 20字節(jié)解析:
      • 版本 0.5字節(jié) 4個2進制位表示怎囚。 ipv4 /ipv6。
      • 首部長度桥胞。0.5字節(jié) 4個2進制位表示恳守。需要乘以4一個數(shù)得到真實的長度。所以 網絡層首部長度范圍是 20~60字節(jié)之間埠戳。
      • 區(qū)分服務井誉。一個字節(jié)蕉扮≌福可以增加處理優(yōu)先級。操作系統(tǒng)級別喳钟。
      • 總長度屁使。2字節(jié)
      • 標識在岂。2字節(jié) ,因為數(shù)據(jù)過大 蛮寂,需要分片蔽午。這個字段相同表示一個數(shù)據(jù)包的分片數(shù)據(jù)。
      • 標志酬蹋。3個二進制位及老。分別是保留位。是否分頁范抓。是否是最后一頁骄恶。
      • 片偏移。12個二進制位匕垫。記錄片偏移僧鲁,開始的位置
      • 生存時間。TTL 經過路由器的個數(shù)象泵, 當這個值減少為0的時候 就返回錯誤寞秃。一般都夠用, 為了防止死循環(huán)偶惠。eg 路由表配置默認路由 倆路由相互踢來踢去春寿。
      • 協(xié)議。記錄封裝的數(shù)據(jù)包采用的協(xié)議是什么協(xié)議 1字節(jié)洲鸠。eg 0 是CSMA/CD堂淡。 6是TCP 協(xié)議。
      • 首部校驗和扒腕。數(shù)據(jù)校驗绢淀。
      • 源IP。
      • 目標IP瘾腰。
傳輸層
  • 傳輸層可以理解為皆的。客戶端和服務器之間通信蹋盆。怎么通信啊 费薄,我怎么讓服務端知道我要發(fā)消息了。 還要讓服務端知道 我發(fā)的消息都發(fā)過去了栖雾。怎么建立連接楞抡,怎么取消連接。 確定 客戶端和服務端如何發(fā)送數(shù)據(jù)的析藕。
  • TCP 和UDT 都屬于傳輸層協(xié)議召廷。 他們區(qū)別為:
對比例 TCP UDP
連接性 面相連接 無連接
可靠性 可靠傳輸,不丟包 不可靠傳輸,可能丟包
首部占用空間
傳輸速率
資源消耗
應用場景 Http,件傳輸FTP竞慢,郵件發(fā)送 音視頻通話先紫,直播
應用層協(xié)議 Http,Https,F(xiàn)TP筹煮,SMTP,DNS DNS
UDP協(xié)議遮精。

無連接,減少建立和釋放連接的開銷败潦。
盡最大能力交付本冲,不保證傳輸成功,可能丟包劫扒。
UDP segment 數(shù)據(jù)包 首部 八字節(jié)眼俊。TCP 至少20字節(jié)。

UDP segment段 數(shù)據(jù)的 首部內容粟关。8字節(jié)疮胖。

源端口號, 目標端口號闷板, UDP 長度 澎灸,UDP 檢驗和。 都是16位二進制遮晚。2字節(jié)大小性昭。

源端口:客戶端臨時開啟的隨機端口。用于請求接受返回數(shù)據(jù)匹配哪次請求的县遣。
目標端口: 取值范圍0~65535 2字節(jié)代表最大數(shù)糜颠。是指服務器 監(jiān)聽的端口。tomact 監(jiān)聽的端口萧求。
UDP長度:首部長度+數(shù)據(jù)長度其兴。
檢驗和:偽首部+首部+數(shù)據(jù) 得到。 虛擬首部有源端口目標端口協(xié)議等夸政。

協(xié)議 默認端+口號
Http TCP+80
https TCP+443
FTP TCP+21
MySQL TCP+3306
DNS TCP/UDP+53
SMTP TCP+25
POP2 TCP+110

TCP協(xié)議元旬。

TCP協(xié)議是傳輸層協(xié)議,對應用層數(shù)據(jù)進行包裝守问,構造傳輸方式匀归,與服務器建立連接的協(xié)議。

面相連接耗帕,傳遞數(shù)據(jù)前需要先建立連接穆端,確認連接通道。
可靠性高仿便,保證不丟包体啰,會有數(shù)據(jù)包重傳概念字柠。
UDP segment 數(shù)據(jù)包 首部 八字節(jié)。TCP 至少20字節(jié)狡赐。

TCP協(xié)議首部 至少20字節(jié) 包含以下部分。
  1. 源端口:
  2. 目標端口:
  3. 序號:除開三次握手四次分手 的連接 之外钦幔,正式發(fā)送請求的過程中的TCP段數(shù)據(jù)枕屉,的時候,序號代表的含義是 此次發(fā)送的數(shù)據(jù)部分的第一個字節(jié)編號鲤氢。 把應用層的數(shù)據(jù)算作一個整體搀擂。對他們的字節(jié)流進行編號。如果出現(xiàn)數(shù)據(jù)過大 分割發(fā)送的時候 序號就會變化卷玉。
  4. 確認號:同樣 建立連接后的含義 是 代表 我接下來期望你給我發(fā)的數(shù)據(jù)的第一個字節(jié)編號是哪個?(http1.0的時候哨颂,發(fā)送端(可以理解為客戶端)發(fā)送數(shù)據(jù)分包的時候這幾個分包發(fā)送是同步的,是需要在發(fā)送給接收端之后相种,接收端返回個消息給發(fā)送端威恼,發(fā)送端再去接著發(fā)送第二部分分包,這個返回確認接收到了的消息攜帶ACK序列號)
  5. 數(shù)據(jù)偏移(也就是首部長度):TCP首部總大小寝并。固定首部大小20字節(jié)箫措。4位2進制位表示,0x0101---0x1111,取值5~15之間衬潦。這個值乘以4代表首部大小斤蔓。 跟網絡層IP協(xié)議的首部大小一樣。都是20~60字節(jié)的大小镀岛。
  6. 保留位:
  7. 標志位:6個二進制位標識弦牡,一個二進制位代表一個。分別是URG(urgent漂羊,緊急)驾锰、ACK、PSH(push走越,)稻据、RST(reset 重置)、SYN(syn买喧,同步)捻悯、FIN(finish,結束)淤毛,等標識今缚。代表本次數(shù)據(jù)包是做什么用的
  8. 窗口:
  9. 檢驗和:和UDP一樣的計算方式 。偽首部+TCP首部+數(shù)據(jù)大小低淡。
  10. 標志指針: 存的是一個 長度姓言, 當標志位 URG 為1 的時候瞬项,才有意義,代表的是 TCP 數(shù)據(jù)部分的 部分前多少位是緊急數(shù)據(jù)何荚。
TCP特點
  1. 可靠傳輸囱淋。面相連接,不丟包餐塘。
    2 流量控制妥衣。
    3 擁塞控制。

標志:1. URG(urgent)緊急指針戒傻, 當為1 的時候税手,首部的緊急指針位置才有值, 保證優(yōu)先傳輸需纳。
2 ACK:確認標志位芦倒,當確認標志位位1 確認號才有意義。
3 PSH (PUSH) 一般用于交互式網絡不翩,很少有兵扬。
4 RST (reset)重置。 當RST 位為1的時候 口蝠,表征TCP連接出現(xiàn)嚴重錯誤周霉,需要重新建立連接。
5 SYN 同步亚皂,用于請求建立和釋放連接作用俱箱。
客戶端發(fā)送到服務端:SYN為1 ACK 為0 代表 第一次握手,序列號seq 為隨機數(shù)Q灭必∧祝客戶端處于等待狀態(tài), 服務端從listening接收這個消息包禁漓。 客戶端告知服務端我要建立連接啦跟衅。
服務端發(fā)送到客戶端 :SYN 為1 ACK 為1 代表第二次握手,序列號 seq 值 是 隨機數(shù)R播歼,ACK的確認號位置發(fā)送個Q+1伶跷。然后服務端發(fā)完這個消息就處于 等待狀態(tài)。 服務端告知客戶端 我知道你要建立練級秘狞,我收到你的消息啦叭莫。 你能收到我消息嗎?
客戶端 在收到服務端第二次握手的消息后烁试, 在構造個 ACK 為1 SYN 為0 雇初,序列號seq為Q+1并且確認號是 上一步的序列號seq+1的值發(fā)送給服務端, 告知服務端减响。我也能接到你的發(fā)的消息靖诗。 然后服務端接收到 此次客戶端消息之后 就知道了 吖 咱倆互相都可以接收到對方消息郭怪, 那么你發(fā)消息給我吧, 就處于等到客戶端發(fā)消息階段了,客戶端再發(fā)送過ACK消息后等待2個ATT之后 如果沒有接收到 其他服務端消息 就開始發(fā)送請求刊橘。
然后客戶端 就把數(shù)據(jù)傳遞給網絡層-》數(shù)據(jù)鏈路層 開始傳遞消息鄙才。

TCP 可靠性傳輸- 自動重傳ARQ協(xié)議 (http1.0的 效率低)

  • ARQ (automatic repeat -reqeust) 自動重傳請求。
    為保證可靠傳輸促绵,發(fā)送數(shù)據(jù)不丟包攒庵, HTTP 1.0 也可以理解為TCP 早期版本 發(fā)送數(shù)據(jù)段時候 是同步的,同步的概念就是一個TCP 數(shù)據(jù)段 (段 是傳輸層數(shù)據(jù)的簡稱)可能過大绞愚, 分成 幾個段發(fā)送, 那么這幾個段在發(fā)送的方式上采用同步方式颖医,就是 我 先傳一個段到接收端位衩,接收端再發(fā)一個確認消息到發(fā)送端,告訴發(fā)送端我接受到了這個段熔萧, 然后發(fā)送端在接收到這個消息之后 在發(fā)送第二段糖驴。
    所以這一個完整流程包含兩個方向的丟包可能。1客戶端發(fā)送到服務端的數(shù)據(jù)丟包佛致,2 .服務端回復給客戶端的消息丟包贮缕。
    在1情況下。 客戶端在發(fā)送消息之后會處于等待狀態(tài)俺榆,如果等待超時 的時候感昼,就再次把這個數(shù)據(jù)段重傳。ARQ自動重傳協(xié)議罐脊。
    再2 情況下 定嗓。服務端接到消息了, 在回傳給客戶端的消息丟包了萍桌。 客戶端仍然是等待超時宵溅,再次把這個數(shù)據(jù)段重傳。不過此時服務端已經收到過這個數(shù)據(jù)段了上炎,服務端會自己處理忽略掉本次傳遞的數(shù)據(jù)恃逻,返回客戶端收到ACK消息。ARQ自動重傳協(xié)議藕施。
    3.服務端發(fā)送確認消息 也有可能 太慢了寇损。 超過客戶端的超時時間了。同樣客戶端還是會重傳信息裳食,同理服務端接受倆條相同信息會忽略最后一次消息润绵。返回確認消息。 這樣客戶端可有可能接到兩次相同的確認消息胞谈, 會自動忽略掉最后一次確認消息尘盼。

TCP可靠性傳輸-連續(xù)ARQ協(xié)議+滑動窗口協(xié)議(http2.0的 效率高)
緩存概念:TCP 發(fā)送消息 有一個緩存機制憨愉,緩存區(qū)。緩存著要發(fā)的數(shù)據(jù)卿捎。
滑動窗口:TCP數(shù)據(jù)首部有一個窗口字段配紫,告知接收端目前緩存區(qū)大小∥缯螅客戶端在發(fā)送消息的時候躺孝,服務端會告知目前窗口大小。然后客戶端根據(jù)窗口大小底桂,可以同時 傳幾個數(shù)據(jù)包 到服務端植袍。這幾個包一起發(fā)送完畢后 服務端會統(tǒng)一給一個ACK確認消息,然后客戶端 再把窗口根據(jù)ACK確認消息 往下移動籽懦, 發(fā)送下一組消息于个。
SACK :選擇性確認技術。 利用TCP 首部的非固定40字節(jié) 來讓發(fā)送端知道 我接收到 哪些數(shù)據(jù)暮顺,哪些數(shù)據(jù)沒接收到厅篓。原理就是發(fā)送端 發(fā)送了連續(xù)的 幾個段的包到接收端, 接收端再接收完畢后 回復發(fā)送端ACK 信息捶码, 并告知發(fā)送端我期望你接下來發(fā)送的段是從什么編號開始羽氮。 這一步是告知發(fā)送端 這個ACK 之前都是連續(xù)的 我都已經接到了。 后面的段時不連續(xù)的惫恼,然后在TCP 首部 非固定字段里面 添加 左邊界+右邊界 告訴你 我哪些是已經收到過的 可以不重發(fā)這些档押。

狀態(tài)碼

100部分

1.100 continue 請求的初始部分已經被服務器接受,期待客戶端繼續(xù)發(fā)送請求部分祈纯。
2 101 切換協(xié)議汇荐,服務器將遵從客戶端請求,切換協(xié)議盆繁。
200部分
200 成功掀淘。
201,接受請求,并且創(chuàng)建了新的資源
202,接受請求油昂,但是尚未處理革娄。
203,已接收請求冕碟。但是返回的信息是來自其他網站拦惋,(跳轉的時候提示 不是本網站信息)。
204 服務器接受了請求安寺, 但是沒有返回內容厕妖, 網站無需變化 類似表單提交,提示已經提交成挑庶。
205 類比204一樣言秸, 但是需要網頁 請求輸入內容软能。
300 重定向。
301 永久重定向举畸。 URI期望你以后都變換了在請求查排, (場景, 瀏覽器書簽什么的更新掉)
302 短暫性重定向抄沮,本次
303 短暫性重定向
304跋核, 內容未修改。無需更新叛买。
307 短暫性重定向 切換 get 為post 砂代。 目前 基本 302 303 307 都會自動切換到post 請求。
400率挣。
400 請求報文錯誤刻伊。java開發(fā)人員 也可以主動的返回狀態(tài)碼 400。
401 身份驗證难礼。
403 服務器拒絕請求娃圆。 權限不夠玫锋。
404 找不到資源蛾茉。
405 請求方法不對。(服務器支持撩鹿,但是java后臺不允許)
406 無法根據(jù)請求的header 配置的特性 相應請求谦炬。
411 服務器不接受不含有效內容長度的header 請求。
500 服務器遇到意外情況并阻止其執(zhí)行請求
501 請求方法不被服務器支持节沦。
503 服務器宕機 處理不過來键思。

跨域: 同源策略 引起的 ajax請求 被拒絕。 同源策略要求 JS請求的時候 請求的接口必須跟自己是在同一服務器上的甫贯, 同源策略: 協(xié)議+域名(IP)+端口 相同吼鳞。
解決方案:
-> CORS Cross-Origin Resource Sharing ,跨域資源共享叫搁。
-> CORS的實現(xiàn)需要客戶端和服務器同時支持赔桌。
客戶端 瀏覽器都默認支持。
服務器:
設置響應頭 Access-Control-v-Origin 設置可以跨域訪問渴逻。 客戶端請求頭里面有個origin 瀏覽器會自動攜帶 請求是來自那個網址疾党。

TCP 可靠性,流量控制惨奕, 擁塞控制(慢啟動雪位,擁塞避免,快重傳梨撞,快回復)雹洗。
可靠性: TCP 協(xié)議 是 有鏈接的特性香罐,會保證數(shù)據(jù)包 一定到達對方,采用的是連續(xù)ARQ 協(xié)議和滑動窗口協(xié)議 實現(xiàn) 可靠性 重傳機制队伟。SACK 技術 穴吹,接收端接收數(shù)據(jù)的時候以一個緩存窗口為單位,這個過程中 如果有包沒傳過來嗜侮, 需要重傳機制港令。慢啟動,擁塞避免锈颗,快重傳顷霹,快回復 網上一大堆。

socket: 不屬于協(xié)議, 而是 基于TCP和UDP 開發(fā)的接口API刊愚。 屬于系統(tǒng)內核API 纲爸,可以實現(xiàn)長連接。各個平臺語言都針對該接口封裝了 各自平臺的 socket朵纷。實現(xiàn)代碼 調用TCP 協(xié)議 和服務器 建立自己的 長連接。
websoctet: H5 提出的一個 協(xié)議永脓。 瀏覽器基本支持袍辞。 搭配HTTP協(xié)議三次TCP握手之后, 轉換為websocket協(xié)議常摧。 需要客戶端支持 協(xié)議轉換 返回httpcode 100操作搅吁。 普通的socket 服務器 是不能直接 鏈接websocket的。

HTTPDNS 落午。
FTP : 文件傳輸協(xié)議谎懦。 倆個端口 鏈接。 顯示連接端口 然后再用另外端口發(fā)送數(shù)據(jù)溃斋。主動模式 被動模式兩種界拦。 以ftp:// 開頭的url FTP協(xié)議 服務器 端口 是20 接收連接命令的端口。 發(fā)送數(shù)據(jù)的端口 主動模式 是21 端口梗劫, 被動模式 是一個隨機端口

最終總結: 瀏覽器輸入個網址 的整體過程享甸。

1

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市在跳,隨后出現(xiàn)的幾起案子枪萄,更是在濱河造成了極大的恐慌,老刑警劉巖猫妙,帶你破解...
    沈念sama閱讀 211,348評論 6 491
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件瓷翻,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機齐帚,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,122評論 2 385
  • 文/潘曉璐 我一進店門妒牙,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人对妄,你說我怎么就攤上這事湘今。” “怎么了剪菱?”我有些...
    開封第一講書人閱讀 156,936評論 0 347
  • 文/不壞的土叔 我叫張陵摩瞎,是天一觀的道長。 經常有香客問我孝常,道長旗们,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 56,427評論 1 283
  • 正文 為了忘掉前任构灸,我火速辦了婚禮上渴,結果婚禮上,老公的妹妹穿的比我還像新娘喜颁。我一直安慰自己稠氮,他們只是感情好,可當我...
    茶點故事閱讀 65,467評論 6 385
  • 文/花漫 我一把揭開白布半开。 她就那樣靜靜地躺著隔披,像睡著了一般。 火紅的嫁衣襯著肌膚如雪稿茉。 梳的紋絲不亂的頭發(fā)上锹锰,一...
    開封第一講書人閱讀 49,785評論 1 290
  • 那天芥炭,我揣著相機與錄音漓库,去河邊找鬼。 笑死园蝠,一個胖子當著我的面吹牛渺蒿,可吹牛的內容都是我干的。 我是一名探鬼主播彪薛,決...
    沈念sama閱讀 38,931評論 3 406
  • 文/蒼蘭香墨 我猛地睜開眼茂装,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了善延?” 一聲冷哼從身側響起少态,我...
    開封第一講書人閱讀 37,696評論 0 266
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎易遣,沒想到半個月后彼妻,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經...
    沈念sama閱讀 44,141評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 36,483評論 2 327
  • 正文 我和宋清朗相戀三年侨歉,在試婚紗的時候發(fā)現(xiàn)自己被綠了屋摇。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,625評論 1 340
  • 序言:一個原本活蹦亂跳的男人離奇死亡幽邓,死狀恐怖炮温,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情牵舵,我是刑警寧澤柒啤,帶...
    沈念sama閱讀 34,291評論 4 329
  • 正文 年R本政府宣布,位于F島的核電站畸颅,受9級特大地震影響白修,放射性物質發(fā)生泄漏。R本人自食惡果不足惜重斑,卻給世界環(huán)境...
    茶點故事閱讀 39,892評論 3 312
  • 文/蒙蒙 一兵睛、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧窥浪,春花似錦祖很、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,741評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至骨稿,卻和暖如春笨鸡,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背坦冠。 一陣腳步聲響...
    開封第一講書人閱讀 31,977評論 1 265
  • 我被黑心中介騙來泰國打工形耗, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人辙浑。 一個月前我還...
    沈念sama閱讀 46,324評論 2 360
  • 正文 我出身青樓激涤,卻偏偏與公主長得像,于是被迫代替她去往敵國和親判呕。 傳聞我的和親對象是個殘疾皇子倦踢,可洞房花燭夜當晚...
    茶點故事閱讀 43,492評論 2 348

推薦閱讀更多精彩內容