TCP連接

持續連接

缺點

• 可能會損害服務器的整體性能
• 需要很多探測包來維持這個連接

優點

• 減少CPU以及內存的使用
• 發生錯誤時，可以在不關閉連接的情況下進行提示
• 減少網絡堵塞，減少了TCP請求

非持續連接

缺點

• 對于每個這樣的連接，在客戶和服務器巾都要分配 TCP 的緩沖區和保持 TCP 變量. 這給 Web 服務器帶來了嚴重的負擔，因為一臺 Web 服務器可能同時服務于數以百計不同 的客戶的請求。

優點

• 其中每個 TCP 連接在服務器發送一個對象后 關閉， 該連接并不為其他的對象而持續下來。 值得注意的是每個 TCP 連接只傳輸一個請求 報文和一個響應報文。

HTTP響應報文

http服務器是無狀態的，這簡化了服務器的設計，并且允許工程師 們去開發可以同時處理數以千計的 TCP 連接的高性能 Web 服務器。

一個初始狀態行

• 協議版本字段
• 狀態碼
• 相應狀態信息

六個首部行

• 服務器用 Connection: close 首部行告訴客戶，發送完報文后 將關閉該 TCP 連接。
• Server: 首部行指示該報文 是由一臺 Apache Web 服務器產生的.它類似于 HTTP 請求報文中的 User-agent
• Date: 首部行指示服務器產生并發送該響應報文的日期和時間。
• Lasl-Modified: 首部行 對既可能在本地客戶也可能在網絡緩存服務器上的對象緩存來說非常重要。
• Conlenl-Length: 首部行指示了被發送對象中的 字節數。
• Conlent-Type: 首部行指示了實體體中的對象是 HTML 文本

空行

實體體

cookie

在 HTTP 響應報文中的一個 cookie 首部 行

在 HTTP 請求報文中的一個 cookie 首部行

在用戶端系統中保留有一個 cookie 文 件，并由用戶的瀏覽器進行管理

位于 Web 站點的一個后端數據庫

web緩存

它是能夠代表 初始 Web 服務器來滿足 HTTP 請求的網絡實體

是服務器又是客戶

Web 緩存器能夠大大減少一個機構的接入鏈路到因特網的通信量

內容分發網絡CDN

• CDN公司在因特網上安裝了許多地理上分散的緩 存器，因而使大量流量實現了本地化。

可能存在的問題：存放在緩存器中的對象副本可能是陳舊的，保存在服務器中的對象自該副本緩存在客戶上以后可能已經被修改了

條件GET方法

請求報文使用 GET 方法

請求報文中包 含一個"If-Modified -Since : "首部行

該 Web 服務器仍發送一個響應報文，但 并沒有在該響應報文中包含所請求的對象。

FTP協議

FTP 使用了兩個并 行的 TCP 連接來傳輸文件， 一個是控制連接 (control connection) ，一個是數據連接( data connection)

FTP 服務器必須在整個會話期間保留用戶的狀態

大大限制了 FTP 同時維持的會話總數。 而另一方面， HTTP 是無狀態的，即它不必對任何用 戶狀態進行追蹤。

電子郵件

異步通信

用戶代理

郵件服務器

簡單郵件傳輸協議SMTP

SMTP 要求每個報文(包括它們的體)使 用 7 比特 ASCII 碼格式

DNS

域名向IP地址的翻譯

主機別名

郵件服務器別名

負載均衡

分布式DNS

單點失敗問題

流量問題

距離問題

維護性問題

TCP的三次握手

第一次握手

• 客戶端向服務器發出連接請求報文，這時報文首部中的同部位SYN=1，同時隨機生成初始序列號 seq=x，此時，TCP客戶端進程進入了 SYN-SENT（同步已發送狀態）狀
  態。TCP規定，SYN報文段（SYN=1的報文段）不能攜帶數據，但需要消耗掉一個序號。這個三次握手中的開始。表示客戶端想要和服務端建立連接

第二次握手

• TCP服務器收到請求報文后，如果同意連接，則發出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要為自己隨機初始化一個序列號 seq=y，此
  時，TCP服務器進程進入了SYN-RCVD（同步收到）狀態。這個報文也不能攜帶數據，但是同樣要消耗一個序號。這個報文帶有SYN(建立連接)和ACK(確認)標志，詢問客戶端
  是否準備好

第三次握手

• TCP客戶進程收到確認后，還要向服務器給出確認。確認報文的ACK=1，ack=y+1，此時，TCP連接建立，客戶端進入ESTABLISHED（已建立連接）狀態。
  TCP規定，ACK報文段可以攜帶數據，但是如果不攜帶數據則不消耗序號。這里客戶端表示我已經準備好

為什么TCP兩次握手不行

網絡不好的情況下，發送的請求沒有立刻到達服務端，而是在某個節點中滯留了，本來已失效，但如果server接收到的話，還是會向client節點發送報文，但請求已經失效，client不會理會

客戶想要查詢一個IP地址

客戶端查詢根服務器

• 查詢com域名解析服務器

  • 查詢域名解析服務器

• 本地域名解析服務器無法解析域名的時候，訪問根域名服務器

  • 權威域名服務器

不屬于層級體系

每個ISP都有

DNS查詢

迭代查詢

• 本地域名服務器向根域名服務器的查詢的迭代查詢
• 當根域名服務器收到本地域名服務器發出的迭代查詢請求報文時，要么給出所要查詢的IP地址，要么告訴本地服務器：“你下一步應當向哪一個域名服務器進行查詢

遞歸查詢

• 主機向本地域名服務器的查詢一般都是采用遞歸查詢
• 如果主機所詢問的本地域名服務器不知道被查詢的域名的IP地址，那么本地域名服務器就以DNS客戶的身份，向其它根域名服務器繼續發出查詢請求報文(即替主機繼續查詢)，而不是讓主機自己進行下一步查詢。

P2P

與傳統網絡技術的區別

• 每個節點既可以從其他節點得到服務，也可以向其他節點提供服務
• 服務器個數有多個
• 數據的一致性不易控制，系統不宜管理
• 可擴展性好

結構

• 分布式哈希表(DHT)結構

  • 都是一個環行拓撲結構
  • 這個結構里每個節點具有一個唯一的節點標識
  • 這種結構多用于文件共享和作為底層結構用于流媒體傳輸

• 樹形結構

  • 所有的節點都被組織在一棵樹中
  • 樹根只有子節點，樹葉只有父節點，其他節點既有子節點也有父節點
  • 信息的流向沿著樹枝流動。最初的樹形結構多用于P2P流媒體直播

• 網狀結構

  • 所有的節點無規則地連在一起，沒有穩定的關系，沒有父子關系
  • 網狀結構為P2P提供了最大的容忍性、動態適應性
  • 流媒體直播、點播

作用

• 分布式科學計算

  • P2P技術可以使得眾多終端的CPU資源聯合起來，服務于一個共同的計算。這種計算一般是計算量巨大、數據極多、耗時很長的科學計算
  • 每次的任務被分片
  • 不影響原有計算機使用的前提下，人們利用分散的CPU資源完成計算任務，并將結果返回給一個或多個服務器，將眾多結果進行整合，以得到最終結果

• 文件共享

  • BitTorrent

    • BitTorrent中的節點在共享一個文件時，首先將文件分片并將文件和分片信息保存在一個流(Torrent)類型文件中，這種節點被形象地稱作“種子”節點
    • 其他用戶在下載該文件時根據Torrent文件的信息，將文件的部分分片下載下來，然后在其他下載該文件的節點之間共享自己已經下載的分片，互通有無，從而實現文件的快速分發

  • 子主題 2

  • 子主題 3

• 流媒體直播與點播

HTTP 把每個對象封裝到它自己的 HTTP 響應報文中， 而 SMTP 則把所有報文對象放在一個報文之中。

有限狀態機

輸入（事件）

輸出（響應）

狀態（必須是可駐留的）

狀態變遷（由下一個事件觸發）

起始態

結束態（可選）

有限狀態機的重要性

• 計算機之所以能夠交互，對各種輸入有“反應”，完全是因為針對每種輸入有預設的響應

• 很多情況下，同一種輸入，我們期望在不同的狀態下有不同的結果——需要標志狀態的機制

• 有限狀態機是描述各種輸入, 輸出與狀態之間關系, 便于協議實現的一種工具

• “智能化的”軟件、硬件邏輯都離不開它

• 凡是沒有設計的輸入，計算機是不理睬的！——狀態機要保證完備性

rdt（可靠數據傳輸協議）

• 1.0

  • 完全可靠的底層信道

    • 沒有比特錯誤
    • 沒有分組丟失

  • 發送方和接收方使用單獨的有限狀態機

    • 發送方發送數據到可靠信道
    • 接收方從可靠信道上讀數據

• 2.0

  • 存在比特錯誤的信道

    • 底層信道可能出現比特錯誤，但分組不丟失并按序到達

      • 用檢驗和檢查比特錯誤

      • 怎樣糾正錯誤？類比打電話過程

        • 肯定確認(ACKs): 接收方明確告訴發送方分組已被成功接收
        • 否定確認 (NAKs): 接收方明確告訴發送方分組有錯誤
        • 發送方接收到NAK后將重傳分組

      • 自動重傳請求（ARQ）協議

        • 基于重傳機制的可靠數據傳輸協議

    • 與rdt1.0比較

      • 接收方錯誤檢測：檢錯技術 Vs 糾錯技術
      • 接收方反饋: 控制報文 (ACK, NAK)
      • 自動重傳：發送方->接收方

• 3.0

  • 具有丟失和錯誤的信道

    • 底層信道也可能丟失分組，包括數據或 ACK分組

      • 問題

        • 檢驗和, 序號, ACK和重傳仍然有用，但還不夠
        • 怎樣檢測丟包？丟包如何處理？需要增加新的協議機制

      • 方法

        • 發送方等待ACK一段“合理的”時間

        • 如果分組 (或 ACK) 僅僅是延遲了(而沒丟失)

          • 重傳將是冗余的, 但是使用序號的方法已經可以解決這個問題了
          • ACK中必須包含所確認分組的序號

        • 如果在這段時間內沒有收到ACK則重傳

        • 需要一個倒計時定時器

udp二元組

IP地址

目的端口號

TCP四元組

源IP地址

源端口

目的IP地址

目的端口

GBN協議

分組頭部包含k-bit序列號

• 窗口尺寸為N，最多允許N個分組未確認

• ACK（n）

  • 確認到序列號n的分組均已被正確吸收

  • ACK機制

    • 發送擁有最高序列號的、已被正確接受的分組的ACK

      • 可能產生重復的

      • 亂序到達的分組

        • 直接丟棄、接收方沒有緩存

• 超時事件

  • 重傳序列號大于N，還未收到ACK的所有分組

    • 累積確認

缺點

• 接收方對每個分組單獨確認

  • 設置緩存機制，緩存亂序到達的分組

• 發送方只重傳哪些沒收到ACK的分組

  • 限制已發送且未確認的分組

計算機網絡運輸層

運輸層為相互通信的應用進程提供邏輯通信

IP協議：點到點（主機到主機）

• 運輸層協議：端到端（進程到進程）

端口的作用：進程間的通信

運輸層很重要的功能：分用和復用

運輸層對收到的報文進行差錯檢測

兩種不同的運輸協議：面向連接的TCP和無連接的UDP

• UDP

  • UDP是無連接的、不保證可靠交付，面向報文、沒有擁塞控制
  • 面向協議
  • UDP使用盡最大努力交付，即不保證可靠交付
  • 支持一對一、一對多、多對一和多對多的交互通信
  • 首部開銷小，只有8個字節
  • 在計算校驗和時，在UDP用戶數據報之前增加12個字節的偽首部。偽首部僅僅是為了計算校驗和

• TCP

  • TCP是面向連接的、提供可靠交付、連接只能是點對點（一對一）、面向字節流，以字節整數倍發送。

  • 應用程序在使用TCP協議之前，必須先建立TCP連接。在傳送數據完畢后，必須釋放已經建立的TCP連接

    • SR協議

      • 當有分組出現超時

        • 重傳
        • 對每個分組分別確認，不再只接收期望的，接到不期望的，就先緩存（設置緩存機制），接到期望的才交付上層
        • 發送方只需要重傳那些沒收到ACK的分組了
        • 產生了接收方窗口（GBN只有發送方窗口），用來緩存，現在有兩窗口了
        • 序列號的位數是K的話，那么得滿足 接收方窗口大小N+發送方N<= 2的k次方，防止因為接收方ACK丟失導致發送重發k號分組，而此時接收方滑到了新窗口，新窗口有新的k號分組（不是原來的，共用序號產生的），導致出錯

  • TCP提供全雙工通信

  • TCP連接是一條虛連接（邏輯連接），而不是一條真正的物理連接

  • 長度可變。化整為零，化零為整

  • TCP把連接作為最基本的抽象

  • TCP把連接的端點叫做套接字（socket）。端口號拼接到IP地址即構成了套接字

  • TCP的流量控制

    • 意義

      • 讓發送方的發送速率不要太快，要讓接收方來得及接收

    • 擁塞控制與流量控制的區別

      • 擁塞控制

        • 防止過多的數據注入網絡，從而避免網絡中的路由器或鏈路過載；是全局性的過程

          • 產生原因：對資源的需求總和大于可用資源

          • 它是一個動態的問題

          • 可以分為開環控制和閉環控制

          • TCP進行擁塞控制的算法有四種：慢開始、擁塞避免、快重傳、快恢復

            • 慢開始：由小到大逐漸增大擁塞窗口數值
            • 擁塞避免：每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1（加法增大）
            • 快重傳：發送方只要一連接收到3個重復確認，立即進行重傳
            • 快恢復：發送方知道只是丟失了個別報文段，不啟動慢開始。調整門限值ssthresh=cwnd/2，設置擁塞窗口cwnd=ssthresh，并開始執行擁塞避免算法

          • 擁塞窗口cwnd，大小取決于網絡的擁塞程度，并且動態地在變化。發送方讓自己的發送窗口等于擁塞窗口

      • 流量控制

        • 指點對點的通信量的控制；協調雙方速率；存在從收方到發放的直接反饋

    • 子主題 3

    • 子主題 4

套接字

• 套接字socket=(IP地址：端口號)

  • 端口的作用

    • 對TCP/IP體系的應用進程進行統一的標志，使運行不同操作系統的計算機的應用進程能夠互相通信

  • 復用

    • 應用層所有的應用進程都可以通過運輸層再傳送到IP層（網絡層）

  • 熟知端口號

    • 數值為0~1023

  • 登記端口號

    • 數值為1024~49151。標志沒有熟知端口號的非常規的服務進程

  • 客戶端使用的端口號（短暫端口號）

• 停止等待協議

  • 停止等待協議的優點是簡單，缺點是信道利用率太低

  • 流水線傳輸可提高信道利用率

  • 發送方每收到一個確認，就把發送窗口向前滑動一個分組的位置。接收方一般采用累積確認的方式，接收方不必對收到的分組逐個發送確認，而是在收到幾個分組后，對按序到達的最后一個分組發送確認

    • 以字節為單位的滑動窗口

      • A的發送窗口一定不能超過B的接收窗口數值

      • 發送窗口的大小代表在還沒收到對方確認消息的情況下，發送端最多可以發送多少數據

      • 接收窗口中是期望接收的數據的序號

      • B只能對按序收到的數據中的最高序號給出確認

      • 發送緩存用來暫時存放

        • 發送應用程序傳送給發送方TCP準備發送的數據
        • TCP已發送出但尚未收到確認的數據

      • 接收緩存用來暫時存放

        • 按序到達的、但尚未被接收應用程序讀取的數據
        • 未按序到達的數據

      • 在同一時刻，A的發送窗口并不總是和B的接收窗口一樣大

        • TCP通常對不按時到達的數據是先臨時存放在接收窗口中，等到字節流中所缺少的字節收到后，再按序交付上層的應用進程
        • TCP要求接收方必須有累積確認的功能，這樣可以減少傳輸開銷

總結

以上是生活随笔為你收集整理的我与TCP连接不得不说的故事的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。