計算機網(wǎng)絡復習

OSI七層模型:

  • 應用層:為應用程序提供服務并規(guī)定應用程序通信相關(guān)得細節(jié)刊棕。包括文件傳輸钢猛,電子郵件察郁,遠程登錄等衍慎。
  • 表示層:將應用處理的信息轉(zhuǎn)換為適合網(wǎng)絡傳輸?shù)母袷剑驅(qū)碜韵乱粚拥臄?shù)據(jù)轉(zhuǎn)換為上層能夠識別的數(shù)據(jù)格式绳锅。因此它主要負責數(shù)據(jù)格式的轉(zhuǎn)換西饵。具體來說,就是將數(shù)據(jù)固有的傳輸格式轉(zhuǎn)換為標準的傳輸格式鳞芙。不同的設備對同一比特流解釋的結(jié)果可能會不同眷柔,因此期虾,使他們保持一致這這一層的主要任務。
  • 會話層:負責建立和斷開通信連接驯嘱,以及數(shù)據(jù)分割等數(shù)據(jù)傳輸相關(guān)的管理
  • 運輸層:起著可靠傳輸?shù)淖饔?丟包重發(fā))镶苞,只在通信雙發(fā)節(jié)點上進行處理,而無需在路由上進行處理鞠评。
  • 網(wǎng)絡層:將數(shù)據(jù)傳輸?shù)侥繕说刂访荆繕说刂房梢允嵌鄠€網(wǎng)絡由路由器連接而成的某一個地址。因此這一層主要負責尋址和路由選擇
  • 鏈路層:負責物理層面上互連的剃幌,節(jié)點之間的通信傳輸巷怜。例如與一個以太網(wǎng)相連的兩個節(jié)點之間的傳輸应役。將0,1序列劃分為具有意義的數(shù)據(jù)幀傳送給對端(數(shù)據(jù)幀的生成與接收。
  • 物理層:負責0芜飘,1比特流 與電壓的高低與光的閃滅之間的轉(zhuǎn)換

TCP/IP四層模型

  • 應用測:負責處理特定的應用程序細節(jié)
  • 運輸層:主要為兩臺主機提供端到端的通信
  • 網(wǎng)絡層:處理分組在互聯(lián)網(wǎng)中的活動,比如路由的選路
  • 鏈路層:包括操作系統(tǒng)中的設備驅(qū)動程序,計算機中對應的網(wǎng)絡接口卡

TCP/IP協(xié)議

TCP/IP協(xié)議是TCP, IP掏愁, HTTP等協(xié)議的集合
互聯(lián)網(wǎng)協(xié)議就是TCP/IP協(xié)議


image.png

包枢劝,幀净捅,數(shù)據(jù)包,消息

  • 包可以說是全能術(shù)語切省。
  • 幀表示數(shù)據(jù)鏈路層中包得單位最岗。
  • 數(shù)據(jù)報是IP和UDP等網(wǎng)絡層以上的分層中包的單位。
  • 段是表示TCP數(shù)據(jù)流中的消息朝捆。
  • 消息是指應用協(xié)議中數(shù)據(jù)的單位般渡。

一個數(shù)據(jù)包的發(fā)送

應用程序處理,對數(shù)據(jù)進行一些編碼等操作右蹦,并建立TCP連接诊杆,TCP根據(jù)應用的指示,負責建立連接何陆,發(fā)送數(shù)據(jù)以及斷開連接晨汹,并添加TCP首部,交付給IP贷盲,IP添加對TCP處理過的數(shù)據(jù)添加首部淘这。IP包生成后,參考路由控制表決定接受該IP包的路由或者主機巩剖,IP包將會發(fā)送給連接這些路由器或主機網(wǎng)絡接口的驅(qū)動程序铝穷,已實現(xiàn)真正的數(shù)據(jù)傳送,如果不知道MAC地址佳魔,利用ARP查找曙聂。


image.png

應用層

  1. 在操作系統(tǒng)中進行通信的是:進程
  2. 進程通過套接字(socket)進行通信
  3. socket是應用程序網(wǎng)絡之間的API
  4. 進程尋址方式:主機地址+端口號
  5. 可供應用程序使用的運輸層服務(簡單介紹)
    • UDP
      1. 不可靠數(shù)據(jù)傳送服務
      2. 沒有擁塞控制
    • TCP
      1. 面向連接的服務
      2. 可靠的數(shù)據(jù)傳送服務
      3. 有擁塞控制

各層對應的網(wǎng)絡設備

原文內(nèi)容:https://blog.csdn.net/qq_25606103/article/details/51288459

應用層:

運輸層:

網(wǎng)絡層:

  • 路由器:
路由器(Router)工作在第三層(即網(wǎng)絡層),它比交換機還要“聰明”一些鞠鲜,它能理解數(shù)據(jù)中的IP地址宁脊,如果它接收到一個數(shù)據(jù)包断国,就檢查其中的IP地址,如果目標地址是本地網(wǎng)絡的就不理會榆苞,如果是其他網(wǎng)絡的稳衬,就將數(shù)據(jù)包轉(zhuǎn)發(fā)出本地網(wǎng)絡。
與工作在網(wǎng)絡物理層坐漏,從物理上劃分網(wǎng)段的交換機不同薄疚,路由器使用專門的軟件協(xié)議從邏輯上對整個網(wǎng)絡進行劃分。
例如赊琳,一臺支持IP協(xié)議的路由器可以把網(wǎng)絡劃分成多個子網(wǎng)段街夭,只有指向特殊IP地址的網(wǎng)絡流量才可以通過路由器。當IP子網(wǎng)中的一臺主機發(fā)送IP分組給同一IP子網(wǎng)的另一臺主機時躏筏,它將直接把IP分組送到網(wǎng)絡上莱坎,對方就能收到。
而要送給不同IP于網(wǎng)上的主機時寸士,它要選擇一個能到達目的子網(wǎng)上的路由器,把IP分組送給該路由器碴卧,由路由器負責把IP分組送到目的地弱卡。
如果沒有找到這樣的路由器,主機就把IP分組送給一個稱為“缺省網(wǎng)關(guān)(default gateway)”的路由器上住册。對于每一個接收到的數(shù)據(jù)包婶博,路由器都會重新計算其校驗值,并寫入新的物理地址荧飞。
網(wǎng)絡中的設備用它們的網(wǎng)絡地址(TCP/IP網(wǎng)絡中為IP地址)互相通信凡人。
IP地址是與硬件地址無關(guān)的“邏輯”地址。目前TCP/IP網(wǎng)絡叹阔,全部是通過路由器互連起來的挠轴,Internet就是成千上萬個IP子網(wǎng)通過路由器互連起來的國際性網(wǎng)絡。
路由器用于連接多個邏輯上分開的網(wǎng)絡耳幢,幾個使用不同協(xié)議和體系結(jié)構(gòu)的網(wǎng)絡岸晦。
路由器利用網(wǎng)絡層定義的“邏輯”上的網(wǎng)絡地址(即IP地址)來區(qū)別不同的網(wǎng)絡,實現(xiàn)網(wǎng)絡的互連和隔離睛藻,保持各個網(wǎng)絡的獨立性启上。
當一個子網(wǎng)傳輸?shù)搅硗庖粋€子網(wǎng)時,可以用路由器完成店印。它具有判斷網(wǎng)絡地址和選擇路徑的功能冈在,過濾和分隔網(wǎng)絡信息流。
一方面能夠跨越不同的物理網(wǎng)絡類型(DDN按摘、FDDI包券、以太網(wǎng)等等)纫谅,另一方面在邏輯上將整個互連網(wǎng)絡分割成邏輯上獨立的網(wǎng)絡單位,使網(wǎng)絡具有一定的邏輯結(jié)構(gòu)兴使。

總結(jié):路由器的主要工作就是為經(jīng)過路由器的每個IP數(shù)據(jù)包尋找一條最佳傳輸路徑系宜,并將該數(shù)據(jù)有效地傳送到目的站點。 路由器的基本功能是发魄,把數(shù)據(jù)(IP報文)傳送到正確的網(wǎng)絡盹牧。

  • 網(wǎng)關(guān):
網(wǎng)關(guān)(Gateway)又稱網(wǎng)間連接器、協(xié)議轉(zhuǎn)換器励幼。
網(wǎng)關(guān)在**網(wǎng)絡層以上**實現(xiàn)網(wǎng)絡互連汰寓,是最復雜的網(wǎng)絡互連設備,僅用于兩個高層協(xié)議不同的網(wǎng)絡互連苹粟。網(wǎng)關(guān)既可以用于廣域網(wǎng)互連有滑,也可以用于局域網(wǎng)互連。
 網(wǎng)關(guān)是一種充當轉(zhuǎn)換重任的計算機系統(tǒng)或設備嵌削。
使用在不同的通信協(xié)議毛好、數(shù)據(jù)格式或語言,甚至體系結(jié)構(gòu)完全不同的兩種系統(tǒng)之間苛秕,網(wǎng)關(guān)是一個翻譯器肌访。
與網(wǎng)橋只是簡單地傳達信息不同,網(wǎng)關(guān)對收到的信息要重新打包艇劫,以適應目的系統(tǒng)的需求吼驶。

總結(jié):網(wǎng)關(guān),在網(wǎng)絡層以上實現(xiàn)網(wǎng)絡互連通店煞,字面意思解釋就是網(wǎng)絡的關(guān)口蟹演。從技術(shù)角度來解釋,就是連接兩個不同網(wǎng)絡的接口顷蟀,比如局域網(wǎng)的共享上網(wǎng)服務器就是局域網(wǎng)和廣域網(wǎng)的接口酒请。

鏈路層:

  • 中繼器:
中繼器(Repeater)是連接網(wǎng)絡線路的一種裝置,常用于兩個網(wǎng)絡節(jié)點之間物理信號的雙向轉(zhuǎn)發(fā)工作。
中繼器是最簡單的網(wǎng)絡互聯(lián)設備,主要完成物理層的功能,負責在兩個節(jié)點的物理層上按位傳遞信息,完成信號的復制鸣个、調(diào)整和放大功能,以此來延長網(wǎng)絡的長度蚌父。
它在OSI參考模型中的位置物理層。
由于存在損耗, 在線路上傳輸?shù)男盘柟β蕰饾u衰減,衰減到一定程度時將造成信號失真,因此會導致接收錯誤毛萌。
中繼器就是為解決這一問題而設計的苟弛。它完成物理線路的連接,對衰減的信號進行放大,保持與原數(shù)據(jù)相同。
中繼器是模擬設備阁将,用于連接兩根電纜段膏秫。中繼器不理解幀、分組和頭的概念,他們只理解電壓值缤削。

總結(jié):位于OSI的物理層窘哈,一種信號放大器,與具體信息無關(guān)亭敢,由于信號在傳輸過程中有衰減滚婉,為了使其傳遞的更遠,需要利用中繼器等設備進行放大帅刀。

  • 集線器:
集線器(Hub)是中繼器的一種形式让腹,區(qū)別在于集線器能夠提供多端口服務,也稱為多口中繼器扣溺。
集線器在OSI/RM中的物理層骇窍。

總結(jié):差不多就是個多端口的中繼器,把每個輸入端口的信號放大再發(fā)到別的端口去锥余,集線器可以實現(xiàn)多臺計算機之間的互聯(lián)腹纳,因為它有很多的端口,每個口都能連計算機驱犹。

  • 網(wǎng)橋:
網(wǎng)橋(Bridge)是一個局域網(wǎng)與另一個局域網(wǎng)之間建立連接的橋梁嘲恍。
網(wǎng)橋是屬于數(shù)據(jù)鏈路層的一種設備,它的作用是擴展網(wǎng)絡和通信手段雄驹,在各種傳輸介質(zhì)中轉(zhuǎn)發(fā)數(shù)據(jù)信號蛔钙,擴展網(wǎng)絡的距離,同時又有選擇地將現(xiàn)有地址的信號從一個傳輸介質(zhì)發(fā)送到另一個傳輸介質(zhì)荠医,并能有效地限制兩個介質(zhì)系統(tǒng)中無關(guān)緊要的通信。

總結(jié):網(wǎng)橋工作在數(shù)據(jù)鏈路層桑涎,將兩個LAN(局域網(wǎng))連起來彬向,根據(jù)MAC地址來轉(zhuǎn)發(fā)幀,可以看作一個“低層的路由器”攻冷。

  • 交換機:
交換機(Swich)工作在第二層(即數(shù)據(jù)鏈路層)娃胆,它要比集線器智能一些,它能分辨出幀中的源MAC地址和目的MAC地址等曼,因此可以在任意兩個端口間建立聯(lián)系里烦,
在數(shù)據(jù)幀的始發(fā)者和目標接收者之間建立臨時的交換路徑,使數(shù)據(jù)幀直接由源地址到達目的地址禁谦。
交換機通過對信息進行重新生成胁黑,并經(jīng)過內(nèi)部處理后轉(zhuǎn)發(fā)至指定端口,具備自動尋址能力和交換作用州泊。但是 交換機并不懂得IP地址丧蘸,它只知道MAC地址。
交換機是使用硬件來完成以往網(wǎng)橋使用軟件來完成過濾遥皂、學習和轉(zhuǎn)發(fā)過程的任務力喷。
交換機速度比HUB(集線器)快刽漂,這是由于HUB不知道目標地址在何處,發(fā)送數(shù)據(jù)到所有的端口弟孟。
而交換機中有一張MAC地址表贝咙,如果知道目標地址在何處,就把數(shù)據(jù)發(fā)送到指定地點拂募,如果它不知道就發(fā)送到所有的端口庭猩。
這樣過濾可以幫助降低整個網(wǎng)絡的數(shù)據(jù)傳輸量,提高效率没讲。但是交換機的功能還不止如此眯娱,它可以把網(wǎng)絡拆解成網(wǎng)絡分支、分割網(wǎng)絡數(shù)據(jù)流爬凑,隔離分支中發(fā)生的故障徙缴,這樣就可以減少每個網(wǎng)絡分支的數(shù)據(jù)信息流量而使每個網(wǎng)絡更有效,提高整個網(wǎng)絡效率嘁信。
現(xiàn)代交換機是這樣處理數(shù)據(jù)幀的:一旦目標頭域(目標地址)已經(jīng)進來了于样,盡管幀的其他部分還沒有到達,則只要輸出線路可以使用潘靖,交換機就開始轉(zhuǎn)發(fā)該幀穿剖,而不需理會幀后面的內(nèi)容,也即是說交換機并沒有使用“存儲—轉(zhuǎn)發(fā)”交換方式卦溢。

總結(jié): 交換機糊余,可以理解為高級的網(wǎng)橋,他有網(wǎng)橋的功能单寂,但性能比網(wǎng)橋強贬芥。交換機和網(wǎng)橋的細微差別就在于:交換機常常用來連接獨立的計算機,而網(wǎng)橋連接的目標是LAN宣决,所以交換機的端口較網(wǎng)橋多蘸劈。

各層的協(xié)議

  • 應用層:
    • HTTP:超文本傳送協(xié)議。是面向事務的應用層協(xié)議尊沸,它是萬維網(wǎng)上能夠可靠地交換文件的重要基礎威沫。http使用面向連接的TCP作為運輸層協(xié)議,保證了數(shù)據(jù)的可靠傳輸洼专。
    • FTP:文件傳輸協(xié)議棒掠。基于TCP
    • POP3:POP3(Post Office Protocol 3)協(xié)議通常被用來接收電子郵件屁商【淠基于TCP
    • STMP:電子郵件協(xié)議。即簡單郵件傳送協(xié)議。SMTP規(guī)定了在兩個相互通信的SMTP進程之間應如何交換信息溯职。SMTP通信的三個階段:建立連接精盅、郵件傳送、連接釋放谜酒√厩危基于TCP
    • Telnet:程終端協(xié)議。telnet是一個簡單的遠程終端協(xié)議僻族,它也是因特網(wǎng)的正式標準粘驰。又稱為終端仿真協(xié)議∈雒矗基于TCP
    • DNS:域名系統(tǒng)蝌数。DNS是因特網(wǎng)使用的命名系統(tǒng),用來把便于人們使用的機器名字轉(zhuǎn)換為IP地址度秘《ド。基于TCP+UDP
      • DNS可以使用UDP或者TCP進行連接,使用的端口號都是53剑梳,大多數(shù)情況下使用UDP進行傳輸唆貌,可靠性靠域名解析器和域名服務器來保證。以下情況會選用TCP進行傳輸:
        1. UDP最大只支持512字節(jié)的數(shù)據(jù)垢乙,如果返回的響應超過512字節(jié)就改用TCP進行傳輸
        2. 區(qū)域傳送是主域名服務器向輔助域名服務器傳送變化的那部分數(shù)據(jù)锨咙,區(qū)域傳送需要使用TCP進行傳輸
    • SNMP:簡單網(wǎng)絡管理協(xié)議。由三部分組成:SNMP本身追逮、管理信息結(jié)構(gòu)SMI和管理信息MIB酪刀。SNMP定義了管理站和代理之間所交換的分組格式。SMI定義了命名對象類型的通用規(guī)則钮孵,以及把對象和對象的值進行編碼骂倘。MIB在被管理的實體中創(chuàng)建了命名對象,并規(guī)定類型油猫。基于UDP
  • 運輸層:
    • TCP
    • UDP
  • 網(wǎng)絡層:
    • RIP:路由信息協(xié)議柠偶,是基于距離矢量算法的路由協(xié)議情妖,利用跳數(shù)來作為計量標準。
    • IP:Internet協(xié)議诱担,負責在主機和網(wǎng)絡之間尋址和路由數(shù)據(jù)包毡证。
    • ICMP:Internet控制報文協(xié)議,發(fā)送消息蔫仙,并報告有關(guān)數(shù)據(jù)包的傳送錯誤料睛。
    • OSPF:開放式最短路徑優(yōu)先,用于在單一自治系統(tǒng)(autonomous system,AS)內(nèi)決策路由
    • BGP:邊界網(wǎng)關(guān)協(xié)議,是自治系統(tǒng)間的路由協(xié)議
    • IGMP:Internet 組管理協(xié)議恤煞,是因特網(wǎng)協(xié)議家族中的一個組播協(xié)議屎勘。該協(xié)議運行在主機和組播路由器之間。
  • 鏈路層:
    • ARP:地址解析協(xié)議居扒,獲得同一物理網(wǎng)絡中的硬件主機地址概漱。 通過ip解析mac
    • RARP:反向地址解析協(xié)議,ARP的逆向協(xié)議喜喂,通過mac解析ip
    • PPP:點對點協(xié)議瓤摧,為在點對點連接上傳輸多協(xié)議數(shù)據(jù)包提供了一個標準方法。PPP 最初設計是為兩個對等節(jié)點之間的 IP 流量傳輸提供一種封裝協(xié)議
    • CSMA/CD:載波監(jiān)聽多點接入/碰撞檢測

IP地址分類玉吁,子網(wǎng)劃分

IP地址分類:

image.png
  • A: 0.0.0.0-127.255.255照弥,其中段0和127不可用
  • B: 128.0.0.0-191.255.255.255
  • C: 192.0.0.0-223.255.255.255
  • D: 224.0.0.0-239.255.255.255
  • E: 240.0.0.0-255.255.255.255,其中段255不可用

其中127.0.0.0~127.255.255.255為環(huán)回地址,用于本地環(huán)回測試等用途
局域網(wǎng)地址:
10.0.0.0~10.255.255.255进副;10.0.0.0/8
172.16.0.0~172.31.0.0这揣;172.16.0.0/12
192.168.0.0~192.168.255.255;192.168.0.0/16


image.png

子網(wǎng)劃分:
主機數(shù) = 2^子網(wǎng)號位數(shù) - 2

UDP和TCP的區(qū)別

  • TCP的優(yōu)點:
    可靠敢会,穩(wěn)定 TCP的可靠體現(xiàn)在TCP在傳遞數(shù)據(jù)之前曾沈,會有三次握手來建立連接,而且在數(shù)據(jù)傳遞時鸥昏,有確認塞俱、窗口、重傳吏垮、擁塞控制機制障涯,在數(shù)據(jù)傳完后,還會斷開連接用來節(jié)約系統(tǒng)資源膳汪。
  • TCP的缺點:
    慢唯蝶,效率低,占用系統(tǒng)資源高遗嗽,易被攻擊 TCP在傳遞數(shù)據(jù)之前粘我,要先建連接,這會消耗時間痹换,而且在數(shù)據(jù)傳遞時征字,確認機制、重傳機制娇豫、擁塞控制機制等都會消耗大量的時間匙姜,而且要在每臺設備上維護所有的傳輸連接,事實上冯痢,每個連接都會占用系統(tǒng)的CPU氮昧、內(nèi)存等硬件資源框杜。 而且,因為TCP有確認機制袖肥、三次握手機制咪辱,這些也導致TCP容易被人利用,實現(xiàn)DOS昭伸、DDOS梧乘、CC等攻擊。
  • UDP的優(yōu)點:
    快庐杨,比TCP稍安全 UDP沒有TCP的握手选调、確認、窗口灵份、重傳仁堪、擁塞控制等機制,UDP是一個無狀態(tài)的傳輸協(xié)議填渠,所以它在傳遞數(shù)據(jù)時非诚夷簦快。沒有TCP的這些機制氛什,UDP較TCP被攻擊者利用的漏洞就要少一些莺葫。但UDP也是無法避免攻擊的,比如:UDP Flood攻擊……
  • UDP的缺點:
    不可靠枪眉,不穩(wěn)定 因為UDP沒有TCP那些可靠的機制捺檬,在數(shù)據(jù)傳遞時,如果網(wǎng)絡質(zhì)量不好贸铜,就會很容易丟包堡纬。

基于上面的優(yōu)缺點,那么:

  • 什么時候應該使用TCP: 當對網(wǎng)絡通訊質(zhì)量有要求的時候蒿秦,比如:整個數(shù)據(jù)要準確無誤的傳遞給對方烤镐,這往往用于一些要求可靠的應用,比如HTTP棍鳖、HTTPS炮叶、FTP等傳輸文件的協(xié)議,POP渡处、SMTP等郵件傳輸?shù)膮f(xié)議镜悉。 在日常生活中,常見使用TCP協(xié)議的應用如下: 瀏覽器骂蓖,用的HTTP FlashFXP积瞒,用的FTP Outlook川尖,用的POP登下、SMTP Putty茫孔,用的Telnet、SSH QQ文件傳輸 …………
  • 什么時候應該使用UDP: 當對網(wǎng)絡通訊質(zhì)量要求不高的時候被芳,并且需要實時性缰贝,要求網(wǎng)絡通訊速度能盡量的快,這時就可以使用UDP畔濒。 比如剩晴,日常生活中,常見使用UDP協(xié)議的應用如下: QQ語音 QQ視頻 TFTP ……

TCP與UDP區(qū)別總結(jié):

  1. TCP面向連接(如打電話要先撥號建立連接);
    UDP是無連接的侵状,即發(fā)送數(shù)據(jù)之前不需要建立連接
  2. TCP提供可靠的服務赞弥。也就是說,通過TCP連接傳送的數(shù)據(jù)趣兄,無差錯绽左,不丟失,不重復艇潭,且按序到達;
    UDP盡最大努力交付拼窥,即不保 證可靠交付
  3. TCP面向字節(jié)流,實際上是TCP把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流;
    UDP是面向報文的.
    UDP沒有擁塞控制蹋凝,因此網(wǎng)絡出現(xiàn)擁塞不會使源主機的發(fā)送速率降低(對實時應用很有用鲁纠,如IP電話,實時視頻會議等)
  4. 每一條TCP連接只能是點到點的;
    UDP支持一對一鳍寂,一對多改含,多對一和多對多的交互通信
  5. TCP首部開銷20字節(jié);
    UDP的首部開銷小,只有8個字節(jié)
  6. TCP的邏輯通信信道是全雙工的可靠信道伐割,
    UDP則是不可靠信道

TCP的連接與斷開

三次握手

image.png
三次握手的原因:
  • 第一次握手:發(fā)送請求(normal)
  • 第二次握手:響應請求(normal)
  • 第三次握手:為了防止失效的請求到達服務器候味,讓服務器錯誤的打開連接。
客戶端發(fā)送的連接請求如果在網(wǎng)絡中滯留隔心,那么就會隔很長一段時間才能收到服務端發(fā)回的連接確認白群。客戶端在等待一個超時重傳時間之后硬霍,就會重新請求連接帜慢,但是這個滯留的連接請求還是會到達服務器,如果不進行三次握手唯卖,那么服務端就會打開兩個連接粱玲,如果有第三次握手,客戶端就會忽略服務器之后發(fā)送的對滯留鏈接請求的連接確認拜轨,不進行第三次握手抽减,因此就不會再打開第二個連接。

四次揮手:

image.png
四次揮手原因:客戶端發(fā)送了FIN連接釋放報文之后橄碾,服務器收到了這個報文卵沉,就進入了CLOSE-WAIT狀態(tài)颠锉,這個狀態(tài)是為了讓服務器端發(fā)送還未傳送完畢的數(shù)據(jù),傳送完畢之后史汗,服務器會發(fā)送FIN連接釋放報文琼掠。
進入TIME-WAIT原因:
  1. 客戶端收到服務器端的FIN報文后進入此狀態(tài),此時并不是直接進入CLOSED狀態(tài)停撞,還需要等待一個時間計時器設置的時間2MSL瓷蛙。這么做有兩個理由:確保最后一確認報文段能夠到達。如果B沒收到A發(fā)送的確認報文段戈毒,那么就會重新發(fā)送連接釋放請求報文段艰猬,A等待一段時間就是為了處理這種情況發(fā)生。
  2. 等待一段時間是為了讓本連接持續(xù)時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡中消失埋市,使得下一個新的連接不會出現(xiàn)舊的連接請求報文段姥宝。

TCP精髓問題:

停止等待協(xié)議

停止等待協(xié)議是tcp保證傳輸可靠的重要途徑,”停止等待”就是指發(fā)送完一個分組就停止發(fā)送,等待對方的確認,只有對方確認過,才發(fā)送下一個分組.
停止等待協(xié)議的優(yōu)點是簡單,但是缺點是信道的利用率太低,一次發(fā)送一條消息,使得信道的大部分時間內(nèi)都是空閑的,為了提高效率,我們采用流水線傳輸,這就與下面兩個協(xié)議有關(guān)系了.

連續(xù)ARQ(自動重傳請求)協(xié)議

它是指發(fā)送方維護著一個窗口,這個窗口中不止一個分組,有好幾個分組,窗口的大小是由接收方返回的win值決定的,所以窗口的大小是動態(tài)變化的,只要在窗口中的分組都可以被發(fā)送,這就使得TCP一次不是只發(fā)送一個分組了,從而大大提高了信道的利用率.并且它采用累積確認的方式,對于按序到達的最后一個分組發(fā)送確認.

滑動窗口

之所以叫滑動窗口協(xié)議,是因為窗口是不斷向前走的,該協(xié)議允許發(fā)送方在停止并等待確認前發(fā)送多個數(shù)據(jù)分組。由于發(fā)送方不必每發(fā)一個分組就停下來等待確認恐疲,因此該協(xié)議可以加速數(shù)據(jù)的傳輸,還可以控制流量的問題棍现。


原文:https://blog.csdn.net/q1007729991/article/details/70142341
  • 發(fā)送方接收到了對方發(fā)來的報文 ack = 33, win = 10旺遮,知道對方收到了 33 號前的數(shù)據(jù)最蕾,現(xiàn)在期望接收 [33, 43) 號數(shù)據(jù)钧忽。發(fā)送方連續(xù)發(fā)送了 4 個報文段假設為 A, B, C, D, 分別攜帶 [33, 35), [35, 36), [36, 38), [38, 41) 號數(shù)據(jù)。
  • 接收方接收到了報文段 A, C省咨,但是沒收到 B 和 D肃弟,也就是只收到了 [33, 35) 和 [36, 38) 號數(shù)據(jù)。接收方發(fā)送回對報文段 A 的確認:ack = 35, win = 10零蓉。
  • 發(fā)送方收到了 ack = 35, win = 10笤受,對方期望接收 [35, 45) 號數(shù)據(jù)。接著發(fā)送了一個報文段 E敌蜂,它攜帶了 [41, 44) 號數(shù)據(jù)箩兽。
  • 接收方接收到了報文段 B: [35, 36), D:[38, 41),接收方發(fā)送對 D 的確認:ack = 41, win = 10. (這是一個累積確認)
  • 發(fā)送方收到了 ack = 41, win = 10章喉,對方期望接收 [41, 51) 號數(shù)據(jù)汗贫。
    ……

需要注意的是,接收方接收 tcp 報文的順序是不確定的秸脱,并非是一定先收到 35 再收到 36落包,也可能是先收到 36,37摊唇,再收到 35咐蝇。
以上僅僅是假設網(wǎng)絡狀況理想,所有的數(shù)據(jù)都會到達接收方的情況巷查,如果出現(xiàn)數(shù)據(jù)丟失:如果一個發(fā)送的報文段在超時時間內(nèi)沒有收到確認有序,那么就重傳這個報文段撮竿。具體機制采用下面的擁塞控制算法。

流量控制

流量控制是為了控制發(fā)送發(fā)的發(fā)送速率笔呀,保證接受方來得及接收
接收方發(fā)送的報文中的窗口字段可以用來控制發(fā)送方窗口的大小,從而影響發(fā)送方的發(fā)送速率髓需,將窗口字段設置為0许师,則發(fā)送方不能發(fā)送數(shù)據(jù)。

擁塞控制(慢開始僚匆、擁塞避免微渠、快重傳、快恢復)

image.png

如果網(wǎng)絡出現(xiàn)擁塞咧擂,分組將會丟失逞盆,此時發(fā)送方會繼續(xù)重傳,從而導致?lián)砣潭雀咚缮辏虼水敵霈F(xiàn)擁塞時云芦,需要控制發(fā)送方的速率。這一點和流量控制很像贸桶,但是出發(fā)點不同:

  • 流量控制是為了讓接收方能來得及接收舅逸。
  • 擁塞控制是為了降低整個網(wǎng)絡的擁塞程度。

TCP主要采用四種算法來進行擁塞控制:慢開始皇筛,擁塞避免琉历,快重傳,快恢復水醋。
發(fā)送方需要維護一個叫做擁塞窗口(cwnd)的狀態(tài)變量旗笔,注意擁塞窗口與發(fā)送窗口的區(qū)別:擁塞窗口只是一個狀態(tài)變量,實際決定發(fā)送方能發(fā)送多少數(shù)據(jù)的還是發(fā)送窗口拄踪。

慢開始與擁塞避免:

慢開始:主機開發(fā)發(fā)送數(shù)據(jù)報時蝇恶,如果立即將大量的數(shù)據(jù)注入到網(wǎng)絡中,可能會出現(xiàn)網(wǎng)絡的擁塞惶桐。慢啟動算法就是在主機剛開始發(fā)送數(shù)據(jù)報的時候先探測一下網(wǎng)絡的狀況艘包,如果網(wǎng)絡狀況良好,發(fā)送方每發(fā)送一次文段都能正確的接受確認報文段耀盗。那么就從小到大的增加擁塞窗口的大小想虎,即增加發(fā)送窗口的大小。
擁塞避免:為了防止cwnd增加過快而導致網(wǎng)絡擁塞叛拷,所以需要設置一個慢開始門限ssthresh狀態(tài)變量舌厨,當cwnd < ssthresh時成倍增長,即1忿薇,2裙椭,4躏哩,8....,當cwnd>=ssthresh時cwn的不再成倍增長揉燃,而是每次增加一扫尺。
如果出現(xiàn)了超時,ssthresh = cwnd / 2炊汤;再重新執(zhí)行慢開始正驻。

快重傳與快恢復

快重傳:

  • 在接收方,要求每次收到的報文段都應該對最后一個已收到的有序報文段進行確認抢腐,例如已經(jīng)收到M1姑曙,M2,此時收到M4迈倍,此時收到M4伤靠,應當發(fā)送對M2的確認。
  • 在發(fā)送方啼染,如果收到三個重復的確認宴合,那么可以知道下一個報文段缺失,此時執(zhí)行快重傳迹鹅,立即重傳下一個報文段形纺,例如收到三個M2,則M3丟失徒欣,立即重傳M3

快恢復:

  • 在快重傳的情況下逐样,只是丟失了個別報文段而不是網(wǎng)絡擁塞,因此執(zhí)行快恢復打肝,令ssthresh = cwnd / 2;cwnd = ssthresh
  • 注意:慢開始和快恢復的快慢指的時cwnd的設定值脂新,而不是cwnd的增長速率。
    慢開始cwnd設定為1粗梭,而快恢復cwnd設定為ssthresh

從瀏覽器輸入某個網(wǎng)站域名(www.v2ex.com)到加載出頁面發(fā)生了什么.

  1. DHCP配置主機信息(獲取本機地址)
  2. ARP解析MAC地址(獲取路由器地址)
  3. DNS解析域名(獲取服務器地址)
  4. HTTP請求頁面(發(fā)送TCP報文段争便,收取TCP報文段)
  5. 渲染頁面
    以上每一份都要了解其具體過程

GET和POST區(qū)別:

  • GET在瀏覽器回退時是無害的,而POST會再次提交請求断医。
  • GET產(chǎn)生的URL地址可以被Bookmark滞乙,而POST不可以。
  • GET請求會被瀏覽器主動cache鉴嗤,而POST不會斩启,除非手動設置。
  • GET請求只能進行url編碼醉锅,而POST支持多種編碼方式兔簇。
  • GET請求參數(shù)會被完整保留在瀏覽器歷史記錄里,而POST中的參數(shù)不會被保留。
  • GET請求在URL中傳送的參數(shù)是有長度限制的垄琐,而POST么有边酒。
  • 對參數(shù)的數(shù)據(jù)類型,GET只接受ASCII字符狸窘,而POST沒有限制墩朦。
  • GET比POST更不安全,因為參數(shù)直接暴露在URL上翻擒,所以不能用來傳遞敏感信息氓涣。
  • GET參數(shù)通過URL傳遞,POST放在Request body中韭寸。

HTTP狀態(tài)碼

狀態(tài)碼為3位十進制數(shù),首位用來區(qū)別類別
1** :信息荆隘,服務器收到請求恩伺,需要請求者繼續(xù)執(zhí)行操作
2** :成功,操作被成功接收并處理
3** :重定向椰拒,需要進一步的操作以完成請求
4** :客戶端錯誤晶渠,請求包含語法錯誤或無法完成請求
5** :服務器錯誤,服務器在處理請求的過程中發(fā)生了錯誤
具體詳見:http://tool.oschina.net/commons?type=5

HTTP1.0,HTTP1.1,HTTP2.0的區(qū)別

HTTP1.0 and HTTP1.1
長連接:
  • HTTP 1.0規(guī)定瀏覽器與服務器只保持短暫的連接燃观,瀏覽器的每次請求都需要與服務器建立一個TCP連接褒脯,服務器完成請求處理后立即斷開TCP連接,服務器不跟蹤每個客戶也不記錄過去的請求缆毁。
  • HTTP 1.1則支持持久連接Persistent Connection, 并且默認使用persistent connection. 在同一個tcp的連接中可以傳送多個HTTP請求和響應. 多個請求和響應可以重疊番川,多個請求和響應可以同時進行. 更加多的請求頭和響應頭(比如HTTP1.0沒有host的字段).
  • HTTP 1.1的持續(xù)連接,也需要增加新的請求頭來幫助實現(xiàn)脊框,例如颁督,Connection請求頭的值為Keep-Alive時,客戶端通知服務器返回本次請求結(jié)果后保持連接浇雹;Connection請求頭的值為close時沉御,客戶端通知服務器返回本次請求結(jié)果后關(guān)閉連接。HTTP 1.1還提供了與身份認證昭灵、狀態(tài)管理和Cache緩存等機制相關(guān)的請求頭和響應頭吠裆。
節(jié)省帶寬
  • HTTP/1.1加入了一個新的狀態(tài)碼100(Continue)±猛辏客戶端事先發(fā)送一個只帶頭域的請求试疙,如果服務器因為權(quán)限拒絕了請求,就回送響應碼401(Unauthorized)抠蚣;如果服務器接收此請求就回送響應碼100效斑,客戶端就可以繼續(xù)發(fā)送帶實體的完整請求了。100 (Continue) 狀態(tài)代碼的使用,允許客戶端在發(fā)request消息body之前先用request header試探一下server缓屠,看server要不要接收request body奇昙,再決定要不要發(fā)request body。
host字段
  • 在HTTP1.0中認為每臺服務器都綁定一個唯一的IP地址敌完,因此储耐,請求消息中的URL并沒有傳遞主機名(hostname)。但隨著虛擬主機技術(shù)的發(fā)展滨溉,在一臺物理服務器上可以存在多個虛擬主機(Multi-homed Web Servers)什湘,并且它們共享一個IP地址。
  • HTTP1.1的請求消息和響應消息都應支持Host頭域晦攒,且請求消息中如果沒有Host頭域會報告一個錯誤(400 Bad Request)闽撤。此外,服務器應該接受以絕對路徑標記的資源請求脯颜。
緩存
  • HTTP/1.1在1.0的基礎上加入了一些cache的新特性哟旗,當緩存對象的Age超過Expire時變?yōu)閟tale對象,cache不需要直接拋棄stale對象栋操,而是與源服務器進行重新激活(revalidation)闸餐。
HTTP1.1 and HTTP2.0
多路復用
  • HTTP2.0使用了多路復用的技術(shù),做到同一個連接并發(fā)處理多個請求矾芙,而且并發(fā)請求的數(shù)量比HTTP1.1大了好幾個數(shù)量級舍沙。
  • 當然HTTP1.1也可以多建立幾個TCP連接,來支持處理更多并發(fā)的請求剔宪,但是創(chuàng)建TCP連接本身也是有開銷的拂铡。
  • TCP連接有一個預熱和保護的過程,先檢查數(shù)據(jù)是否傳送成功葱绒,一旦成功過和媳,則慢慢加大傳輸速度。因此對應瞬時并發(fā)的連接哈街,服務器的響應就會變慢留瞳。所以最好能使用一個建立好的連接,并且這個連接可以支持瞬時并發(fā)的請求骚秦。
數(shù)據(jù)壓縮

HTTP1.1不支持header數(shù)據(jù)的壓縮她倘,HTTP2.0使用HPACK算法對header的數(shù)據(jù)進行壓縮,這樣數(shù)據(jù)體積小了作箍,在網(wǎng)絡上傳輸就會更快硬梁。

服務器推送
  • 意思是說,當我們對支持HTTP2.0的web server請求數(shù)據(jù)的時候胞得,服務器會順便把一些客戶端需要的資源一起推送到客戶端荧止,免得客戶端再次創(chuàng)建連接發(fā)送請求到服務器端獲取。這種方式非常合適加載靜態(tài)資源。
  • 服務器端推送的這些資源其實存在客戶端的某處地方跃巡,客戶端直接從本地加載這些資源就可以了危号,不用走網(wǎng)絡,速度自然是快很多的素邪。

HTTPS

將原本在TCP上傳輸?shù)腍TTP協(xié)議外莲,用SSL進行傳輸,SSL再通過TCP傳輸


image.png

HTTP緩存機制(cache-control兔朦、Expires之類的一系列請求與相應報頭字段)

推薦:https://blog.csdn.net/byeweiyang/article/details/80127685

  • private:告知緩存服務器偷线,該緩存只允許返回給特定的用戶
  • public:緩存可以給任何一個用戶使用

session和cookie的區(qū)別,禁用cookie后怎么辦

session是存放在服務器沽甥。
cookie存放在瀏覽器声邦。
session本質(zhì)上是用根據(jù)傳過來的cookie通過哈希表還找到對應的數(shù)據(jù)的,所以本質(zhì)上沒什么區(qū)別摆舟。
如果cookie被禁用亥曹,正常的session也會失效。
常用的辦法有:
URL重寫:把用來存儲session的cookie放到url的參數(shù)里
隱藏表單:通過一個hidden的表單來存儲

DNS解析的過程

宏觀:
1.找緩存
2.找本機host
3.找dns服務器
具體步驟會涉及DHCP盏檐,ARP等協(xié)議對應的過程

常用協(xié)議的端口

20/tcp FTP 文件傳輸協(xié)議數(shù)據(jù)傳輸端口
21/tcp FTP 文件傳輸協(xié)議連接端口
22/tcp SSH 安全登錄歇式、文件傳送(SCP)和端口重定向
23/tcp Telnet 不安全的文本傳送
25/tcp SMTP Simple Mail Transfer Protocol (E-mail)
53/udp or TCP DNS
69/udp TFTP Trivial File Transfer Protocol
79/tcp finger Finger
80/tcp HTTP 超文本傳送協(xié)議 (WWW)
88/tcp Kerberos Authenticating agent
110/tcp POP3 Post Office Protocol (E-mail)
113/tcp ident old identification server system
119/tcp NNTP used for usenet newsgroups
220/tcp IMAP3
443/tcp HTTPS used for securely transferring web pages

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末驶悟,一起剝皮案震驚了整個濱河市胡野,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌痕鳍,老刑警劉巖硫豆,帶你破解...
    沈念sama閱讀 221,635評論 6 515
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異笼呆,居然都是意外死亡熊响,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,543評論 3 399
  • 文/潘曉璐 我一進店門诗赌,熙熙樓的掌柜王于貴愁眉苦臉地迎上來汗茄,“玉大人,你說我怎么就攤上這事铭若『樘迹” “怎么了?”我有些...
    開封第一講書人閱讀 168,083評論 0 360
  • 文/不壞的土叔 我叫張陵叼屠,是天一觀的道長瞳腌。 經(jīng)常有香客問我,道長镜雨,這世上最難降的妖魔是什么嫂侍? 我笑而不...
    開封第一講書人閱讀 59,640評論 1 296
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上挑宠,老公的妹妹穿的比我還像新娘菲盾。我一直安慰自己,他們只是感情好痹栖,可當我...
    茶點故事閱讀 68,640評論 6 397
  • 文/花漫 我一把揭開白布亿汞。 她就那樣靜靜地躺著,像睡著了一般揪阿。 火紅的嫁衣襯著肌膚如雪疗我。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 52,262評論 1 308
  • 那天南捂,我揣著相機與錄音吴裤,去河邊找鬼。 笑死溺健,一個胖子當著我的面吹牛麦牺,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播鞭缭,決...
    沈念sama閱讀 40,833評論 3 421
  • 文/蒼蘭香墨 我猛地睜開眼剖膳,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了岭辣?” 一聲冷哼從身側(cè)響起吱晒,我...
    開封第一講書人閱讀 39,736評論 0 276
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎沦童,沒想到半個月后仑濒,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 46,280評論 1 319
  • 正文 獨居荒郊野嶺守林人離奇死亡偷遗,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,369評論 3 340
  • 正文 我和宋清朗相戀三年墩瞳,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片氏豌。...
    茶點故事閱讀 40,503評論 1 352
  • 序言:一個原本活蹦亂跳的男人離奇死亡喉酌,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出泵喘,到底是詐尸還是另有隱情泪电,我是刑警寧澤,帶...
    沈念sama閱讀 36,185評論 5 350
  • 正文 年R本政府宣布涣旨,位于F島的核電站歪架,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏霹陡。R本人自食惡果不足惜和蚪,卻給世界環(huán)境...
    茶點故事閱讀 41,870評論 3 333
  • 文/蒙蒙 一止状、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧攒霹,春花似錦怯疤、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,340評論 0 24
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至抠刺,卻和暖如春塔淤,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背速妖。 一陣腳步聲響...
    開封第一講書人閱讀 33,460評論 1 272
  • 我被黑心中介騙來泰國打工高蜂, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人罕容。 一個月前我還...
    沈念sama閱讀 48,909評論 3 376
  • 正文 我出身青樓备恤,卻偏偏與公主長得像,于是被迫代替她去往敵國和親锦秒。 傳聞我的和親對象是個殘疾皇子露泊,可洞房花燭夜當晚...
    茶點故事閱讀 45,512評論 2 359

推薦閱讀更多精彩內(nèi)容

  • 1、TCP為什么需要3次握手旅择,4次斷開惭笑? “三次握手”的目的是“為了防止已失效的連接請求報文段突然又傳送到了服務端...
    杰倫哎呦哎呦閱讀 3,485評論 0 6
  • 運輸層協(xié)議概述 從通信和信息處理的角度看,運輸層向它上面的應用層提供通信服務砌左,它屬于面向通信部分的最高層脖咐,同時也是...
    srtianxia閱讀 2,410評論 0 2
  • 協(xié)議的定義:在兩個或多個通信實體間所交換消息的格式和順序铺敌,及發(fā)出/或收到一個消息或者其他事件時應該采取的行動汇歹。 協(xié)...
    BEYOND黃閱讀 815評論 0 1
  • 計算機網(wǎng)絡復習知識點 基本知識點 1.OSI參考模型(七層體系結(jié)構(gòu)) 物理層 - 數(shù)據(jù)鏈路層 - 網(wǎng)絡層 - 運輸...
    01_小小魚_01閱讀 537評論 0 0
  • 最近在復習笑來老師的專欄《通往財富自由之路》,收獲良多偿凭。感覺時間過得好快产弹,但自己進步的速度有點慢,沒有趕上時間的節(jié)...
    韓珂的進化之旅閱讀 166評論 0 0