OSI參考模型:應用層、表示層、會話層、傳輸層、網絡層、數據鏈路層、物理層
協議棧(Protocol Stack)是指網絡中各層協議的總和
是連接因特網中各局域網、廣域網的設備,它會根據信道的情況自動選擇和設定路由,以最佳路徑,按前后順序發送信號。
路由器有兩個部分組成,WAN和LAN,WAN是用來撥號的,是讓路由自身能上網的一個部分,LAN是用來局域網內交換數據的,跟交換機的作用一樣,我們的電腦插在LAN口才能上網
路由內置DHCP服務器,可以為使用路由的電腦自動分配IP
路由器在網絡層
是一種用于電(光)信號轉發的網絡設備。作用可以簡單的理解為將一些機器連接起來組成一個局域網。它可以為接入交換機的任意兩個網絡節點提供獨享的電信號通路。
他只有LAN,沒有WAN
把網線插進交換機的任意接口,把電腦1插進交換機的任意接口,把電腦2插進交換機的任意接口,這樣兩臺電腦都需要撥號才能上網,以此看來交換機是用來數據交換的
交換機在數據鏈路層(也有多層交換機:數據鏈路層+ 部分網絡層)
把光纖轉換成直接能插在電腦上的網線
應用層(OSI模型的會話層和表示層合并到應用層中)
傳輸層
網際互聯層(對應于OSI參考模型的網絡層)也經常成為IP層
網絡接入層或者主機到網絡層(OSI參考模型中的物理層和數據鏈路層相對應)
IP層中包含網際控制報文協議(ICMP:Internet Control Message Protocol)和地址解析協議ARP,實際上他們并不是IP層的一部分,但直接同IP層一起工作。ICMP用于傳遞差錯信息、時間、回顯、網絡信息等報文控制數據 。ARP處于IP和數據鏈路層之間,它是在32位IP地址和48位局域網地址之間執行翻譯的協議
以太網數據格式:
以太網用48bit(6字節)來表示原地址和目的地址。這里的源地址和目的地址指的是硬件地址,例如網卡的MAC地址。
在地址后面是兩個字節的表示類型的字段,例如0800表示幀的數據為IP數據,0806表示此幀為ARP請求
類型字段之后的數據,對于以太網,規定數據段的大小范圍是46個字節到1500個字節,不足的數據要用空字符填滿。例如ARP協議的數據格式為28個字節,為了符合規范,其后有18個字節的占位符用于滿足最少46字符的要求
數據段的長度有一個最大值,以太網為1500,這個特性為MTU,即最大傳輸單元。如果IP層有一個要傳送的數據長度比MTU大,在IP層數據要進行分片,使得每個片都小于MTU
CRC字段用于對幀內數據進行校驗,保證數據傳輸的正確性,通常由硬件實現,例如網卡設備中實現網絡數據的CRC校驗
以太網的頭部14字節的特點在某些平臺的實現上會造成效率上的問題,例如4字節對齊的平臺,在取得IP數據的時候通常會重新復制一次
ARP(Address Resolution Protocol,地址解析協議)是一個位于TCP/IP協議棧中的網絡層,負責將某個IP地址解析成對應的MAC物理地址。
在以太網為基礎的局域網中,每個網絡接口都有一個硬件地址,這是一個48bit的值,標識不同的以太網設備,在局域網中的必須知道網絡設備硬件地址才能向目的主機發送數據,而在網際網中數據傳輸的目的地址是IP地址,數據要能夠正常地傳輸,必須建立IP地址和硬件地址的映射記錄,
32位IP地址到48位硬件地址映射的ARP協議
IP層的主要目的是提供子網的互聯,形成較大的網絡,使不同的子網之間能傳輸數據。
IP層的主要作用:
IPV4的IP地址32位,由四組十進制數組成,每組數值范圍0-255,中間.分隔,
一個IP地址由IP地址類型、網絡ID、主機ID組成
網絡類型標識符標識本IP地址所屬的類型
網絡ID標識IP標識設備或主機所在的網絡
主機ID標識網絡上的工作站、服務器或者路由選擇器。
主機ID全為0的地址表示某個網絡的網絡地址
主機ID全為1的地址表示廣播地址
IP全為0的地址表示主機本身,發往此IP地址的數據分組由本機接收
IP全為1的地址表示有限廣播地址
IP地址127.0.0.1是特殊的回環地址,一般用于本地測試使用
IP協議是用于將多個包交換網絡連接起來的,它在源地址和目的地址之間傳送一種稱之為數據包的東西,它還提供對數據大小的重新組裝功能,以適應不同網絡對包大小的要求。
網絡層IP提供的是一種不可靠的服務。它只是盡可能快地把分組從源節點送到目的節點,但不提供任何可靠性的保證。
用于傳送差錯信息、時間、回顯、網絡信息等報文控制數據,常用來檢測網絡通不通,主機是否可達,路由器是否可用。
ICMP協議可分為兩大類,一是查詢報文,一是差錯報文。
UDP:user data protocol 用戶數據報文協議--- 一個不可靠的、無連接協議;適用于不怕數據丟失、不需要對報文進行排序、流量控制的場景
UDP協議不保證數據報文傳輸的順序、不保證數據準確到達
UDP協議相比較于TCP協議執行速度比TCP快得多,因為UDP協議簡單得多,對系統造成的負載低
應用場景:流媒體的傳輸、域名服務器、嵌入式機頂盒系統
TCP:transmission control protocol 傳輸控制協議---在不可靠的ip層上,提供了一個可靠的、面向連接的、流控的傳輸層協議,為了提供這種可靠的服務,TCP采用了超時重傳、滑動窗口、發送和接收端到端的確認分組等機制,保證接收端能接收到發送端的所有包,并順序與發出順序一致。
滑動窗口:接收方通過通告發送方自己的窗口大小,從而控制發送方的發送速度,從而達到防止發送方發送速度過快而導致自己被淹沒的目的。
TCP特點:
未連接隊列
在三次握手協議中,服務器維護一個未連接隊列,該隊列為每個客戶端的SYN包(syn=j)開設一個條目,該條目表明服務器已收到SYN包,并向客戶發出確認,正在等待客戶的確認包。這些條目所標識的連接在服務器處于SYN_RECV狀態,當服務器收到客戶的確認包時,刪除該條目,服務器進入ESTABLISHED狀態。
https://www.cnblogs.com/Andya/p/7272462.html
答:雖然按道理,四個報文都發送完畢,我們可以直接進入CLOSE狀態了,但是我們必須假象網絡是不可靠的,有可以最后一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。
服務器端的資源分配是在二次握手時分配的,而客戶端的資源是在完成三次握手時分配的,所以服務器容易受到SYN洪泛***,SYN***就是Client在短時間內偽造大量不存在的IP地址,并向Server不斷地發送SYN包,Server則回復確認包,并等待Client確認,由于源地址不存在,因此Server需要不斷重發直至超時,這些偽造的SYN包將長時間占用未連接隊列,導致正常的SYN請求因為隊列滿而被丟棄,從而引起網絡擁塞甚至系統癱瘓。
防范SYN***措施:降低主機的等待時間使主機盡快的釋放半連接的占用,短時間受到某IP的重復SYN則丟棄后續請求。
TCB傳輸控制塊Transmission Control Block,存儲每一個連接中的重要信息,如TCP連接表,到發送和接收緩存的指針,到重傳隊列的指針,當前的發送和接收序號。
SYN=1的報文段不能攜帶數據
因為當Server端收到Client端的SYN連接請求報文后,可以直接發送SYN+ACK報文。其中ACK報文是用來應答的,SYN報文是用來同步的。但是關閉連接時,當Server端收到FIN報文時,很可能并不會立即關閉SOCKET,所以只能先回復一個ACK報文,告訴Client端,"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了,我才能發送FIN報文,因此不能一起發送。故需要四步握手。
HTTP協議是Hyper Text Transger Protocal(超文本傳輸協議)的縮寫
用于從萬維網(www:World Wide Web)服務器傳輸超文本到客戶端的傳輸協議
HTTP是一個 基于TCP/IP通信協議來傳遞數據,默認HTTP的端口號為80
HTTP是一個屬于應用層協議
由請求和響應構成,是一個標準的客戶端服務器模型
HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記
HTTP是一個無狀態的協議,無狀態是指協議對于事務處理沒有記憶能力
竊聽風險:***可以獲取通信內容。
篡改風險:***可以修改通信內容。
冒充風險:***可以冒充他人身份參與通信
SSL是Secure Sockets Layer的縮寫,中文叫做“安全套接層”
TLS是Transport Layer Security”的縮寫,中文叫做“傳輸層安全協議”
SSL是指安全套接層協議(以及傳輸層協議TLS),位于TCP/IP協議與各種應用層協議之間,為數據通訊提供安全支持。
HTTPS 協議(HyperText Transfer Protocol over Secure Socket Layer) 還是要基于 TCP 來傳輸(所謂的“HTTP over SSL”,實際上是在原有的 HTTP 數據外面加了一層 SSL 的封裝。HTTP 協議原有的 GET、POST 之類的機制,基本上原封不動)
HTTPS協議承載于TLS或SSL協議層之上,HTTPS的端口號為443
保密性(防泄密-有信息都是加密傳播,***無法竊聽)、完整性(防篡改-具有校驗機制,一旦被篡改,通信雙方會立刻發現)、真實性(防假冒-配備×××書,防止身份被冒充)
HTTP協議通常承載于TCP協議之上; HTTP的長連接和短連接本質上是TCP長連接和短連接。HTTP屬于應用層協議,在傳輸層使用TCP協議,在網絡層使用IP協議。 IP協議主要解決網絡路由和尋址問題,TCP協議主要解決如何在IP層之上可靠地傳遞數據包,使得網絡上接收端收到發送端所發出的所有包,并且順序與發送順序一致。TCP協議是可靠的、面向連接的。
網絡層: IP協議/ARP協議
傳輸層:TCP/UDP協議
應用層:HTTP協議
Socket是應用層與TCP/IP協議族通信的中間軟件抽象層,它是一組接口。在設計模式中,Socket其實就是一個門面模式,它把復雜的TCP/IP協議族隱藏在Socket接口后面,對用戶來說,一組簡單的接口就是全部,讓Socket去組織數據,以符合指定的協議。
主機 A 的應用程序要能和主機 B 的應用程序通信,必須通過 Socket 建立連接,而建立 Socket 連接必須需要底層 TCP/IP 協議來建立 TCP 連接。建立 TCP 連接需要底層 IP 協議來尋址網絡中的主機。我們知道網絡層使用的 IP 協議可以幫助我們根據 IP 地址來找到目標主機,但是一臺主機上可能運行著多個應用程序,如何才能與指定的應用程序通信就要通過 TCP 或 UPD 的地址也就是端口號來指定。
HTTP 對 TCP 連接的使用,分為兩種方式:俗稱“短連接”和“長連接”(“Keep-Alive”或“Persistent Connection”)
長連接:當一個網頁打開完成后,客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉,客戶端再次訪問這個服務器時,會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接,它有一個保持時間,可以在不同的服務器軟件(如Apache)中設定這個時間。實現長連接需要客戶端和服務端都支持長連接。
使用長連接的HTTP協議,會在響應頭加入這行代碼:Connection:keep-alive
如果HTTP1.1版本的HTTP請求報文不希望使用長連接,則要在HTTP請求報文首部加上Connection: close。
TCP的?;罟δ苤饕獮榉掌鲬锰峁?試圖在服務端器端檢測到半開放的連接,并根據響應決定是否關閉連接
短連接:客戶端和服務器每進行一次HTTP操作,就建立一次連接,任務結束就中斷連接。雙方任意都可以發起close操作,不過一般都是client先發起close操作。
短連接的優點是:管理起來比較簡單,存在的連接都是有用的連接,不需要額外的控制手段。
建立連接——數據傳輸——關閉連接...建立連接——數據傳輸——關閉連接
長連接的操作步驟是:
建立連接——數據傳輸...(保持連接)...數據傳輸——關閉連接
長連接可以省去較多的TCP建立和關閉的操作,減少浪費,節約時間。對于頻繁請求資源的客戶來說,較適用長連接。不過這里存在一個問題,存活功能的探測周期太長,還有就是它只是探測TCP連接的存活,屬于比較斯文的做法,遇到惡意的連接時,?;罟δ芫筒粔蚴沽?。在長連接的應用場景下,client端一般不會主動關閉它們之間的連接,Client與server之間的連接如果一直不關閉的話,會存在一個問題,隨著客戶端連接越來越多,server早晚有扛不住的時候,這時候server端需要采取一些策略,如關閉一些長時間沒有讀寫事件發生的連接,這樣可 以避免一些惡意連接導致server端服務受損;如果條件再允許就可以以客戶端機器為顆粒度,限制每個客戶端的最大長連接數,這樣可以完全避免某個蛋疼的客戶端連累后端服務。
短連接對于服務器來說管理較為簡單,存在的連接都是有用的連接,不需要額外的控制手段。但如果客戶請求頻繁,將在TCP的建立和關閉操作上浪費時間和帶寬。
長連接和短連接的產生在于client和server采取的關閉策略,具體的應用場景采用具體的策略,沒有十全十美的選擇,只有合適的選擇。
判斷傳輸數據是否達到了Content-Length指示的大??;
動態生成的文件沒有Content-Length,它是分塊傳輸(chunked),這時候就要根據chunked編碼來判斷,chunked編碼的數據在最后有一個空chunked塊,表明本次傳輸數據結束。
keepalive_timeout 20; --長連接timeout
keepalive_requests 8192; --每個連接最大請求數
長連接多用于操作頻繁,點對點的通訊,而且連接數不能太多情況,。每個TCP連接都需要三步握手,這需要時間,如果每個操作都是先連接,再操作的話那么處理速度會降低很多,所以每個操作完后都不斷開,次處理時直接發送數據包就OK了,不用建立TCP連接。例如:數據庫的連接用長連接, 如果用短連接頻繁的通信會造成socket錯誤,而且頻繁的socket 創建也是對資源的浪費。
而像WEB網站的http服務一般都用短鏈接,因為長連接對于服務端來說會耗費一定的資源,而像WEB網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源,如果用長連接,而且同時有成千上萬的用戶,如果每個用戶都占用一個連接的話,那可想而知吧。所以并發量大,但每個用戶無需頻繁操作情況下需用短連好。
設置請求頭域
在首部字段中設置Connection:keep-alive 和Keep-Alive: timeout=60,表明連接建立之后,空閑時間超過60秒之后,就會失效。如果在空閑第58秒時,再次使用此連接,則連接仍然有效,使用完之后,重新計數,空閑60秒之后過期。
設置HTTP長連接,無過期時間;在首部字段中只設置Connection:keep-alive,表明連接永久有效。connection字段只有服務端設置才有效。
connection字段只有服務端設置才有效。
客戶端設置Connection: Keep-Alive和Keep-Alive: timeout=60, 服務端設置Connection: Keep-Alive和Keep-Alive: timeout=5。
HTTP協議是無狀態的,指的是協議對于事務處理沒有記憶能力,服務器不知道客戶端是什么狀態。也就是說,打開一個服務器上的網頁和上一次打開這個服務器上的網頁之間沒有任何聯系。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。