第VI章は、TCPIP --- ---輸送層TCPUDPを示しています

ハッハッハハッハッハ

TCPIP识别一个进行通信的应用需要5大要素

• 送信元IPアドレス
• 宛先のIPアドレス
• 送信元ポート
• 宛先ポート
• 契約番号

---

0-1023周知のポート番号
1024から49151これらのポートは、正式に登録されているが、任意の通信のために使用することができる
の49152から65535オペレーティングシステムの動的割り当てポート番号
次のようにいくつかのよく知られているポート番号であります

• 20 FTPデータファイル転送[Deafultデータ]
• 21 FTPファイル転送[制御]
• 22 SSH
• 23才能
• 25 SMTP簡易メール転送プロトコル
• です43 NICNAME
• 53ドメインドメイン名サーバー
• 80 HTTP
• 101ホストNICホスト名サーバ
• 443 HTTPS

UDP

多くの場合、以下の分野で使用されます

• 少ない総DNS、SNMPパケット通信など
• オーディオおよびその他のマルチメディアビデオ通信
• LANなどの特定のネットワークに定義されたアプリケーション通信
• 同報通信（ブロードキャストおよびマルチキャスト）

TCP

確認応答シーケンス番号

ウィンドウ制御機構とシーケンス番号の信頼性の高い伝送をチェックして、TCP受信確認再送制御接続管理

確認応答ACK肯定
否定確認応答NACKの否定応答

• 端の端の確認応答を送信データQ1待機を送信した後

  • 一定時間は、送信側がデータを再送失われたことを考える承認されるまで待ちません
    • データを受信して​​いないことの確認は、戻りの途中で失われることがあります
    • 最終確認を達するの遅れがあるかもしれません
  • メカニズム送信端を繰り返すに従って但是对接收端可能重复收到数据 简直就是灾难 需要处理这种情况

• 受信したデータを受信したか否かを判断することができるかどうかを識別するためのメカニズムのA1ニーズ

  • 繰り返し再送制御機能をすることができる等の確認応答プロセス制御、序列号シーケンス番号を実現することが按顺序、送信データの各バイト（8バイト）には、ID番号にマークされています
  • 下記に示すように、

  

再送タイムアウト

• Q1のタイムアウトが定義された方法
• A1 最好找到一个 确认应答一定时间内一定能在这个时间段内返回
• Q2 TCP要求不论处在何种网络都提供高性能通信 并且无论网络拥堵情况发生何种变化 都必须保持这一特性
• A2 每次发包时都计算往返时间及其偏差 往返时间和偏差(RTT时间波动的值 方差)相加 超时重发时间就是这个和在大一丢丢的
• A3 在BSD的Unix以及Windows中 超时都是按0.5s为单位 偏差的最小值也是0.5 所以最小的重发时间时1s
• A4 数据被重发之后若还是收不到则再次发送 超时等待时间会2倍 4倍函数延长 数据也不会无限反复的重复 到达一定的次数后如果仍没有任何确认应答 则会判断网络或对端主机异常 强制管理连接并通知应用程序
• 如下图

连接管理

三次握手 四次挥手

MSS最大消息长度
TCP在传送大量消息时 是以MSS进行分割 重发也是也MSS为单位
MSS是在三次握手时计算出来的 在发送SYN请求时会在TCP首部写入MSS选项 会在两者中选一个比较小的值投入使用

窗口

为每个数据包进行确认应答的缺点是包往返时间越长网络的吞吐量越差
引入窗口概念 窗口的滑动如下

窗口控制和重发控制如下图 P211

流控制

窗口大小这个字段是由接收端控制的 TCP首部中有一个字段通知窗口大小 具体过程如下

拥塞控制 P213

通信刚开始就发送大量数据 可能存在隐藏问题
在网络拥堵时 如果突然出现一个较大量的数据可能导致网络瘫痪
TCP为了防止该问题 在通信一开始便会通过一个慢启动算法得出的数值对发送数据量进行控制
定义了一个拥塞窗口的概念

提高网络利用率的规范

• Nagle算法 尽在下列任意一种条件满足才能发送数据 这个算法可能导致某种程度的延迟因此在窗口系统(X Window System)以及继续控制等领域中使用TCP时往往会关闭该算法的启用
  • 已发送的数据全部都已经收到确认应答
  • 可以发送最大段长度MSS的数据时
• 延迟确认应答
  • 每次都立刻回复确认应答的话 可能会返回一个较小的窗口(因为刚接收完数据 缓冲区已满)在流控制一节可以看到接收端可以控制窗口大小
  • 延迟机制如下
    • 在没有收到2x最大段长度的数据为止不做确认应答(根据操作系统不同 有时不论数据大小 只要收到两个包就即可返回确认应答的情况) 总而言之就是各种机制延迟确认应答
    • 在其他情况下 最大延迟0.5s发送确认应答 很多操作系统设置为0.2s 延迟超过0.5时很有可能导致重发数据 这个时间越小 CPU的负荷越高性能也下降 时间越大越有可能触发发送主机的重发处理
• 捎带应答
  • TCP的确认应答和回执数据一起返回通过一个包发送
  • そのような接続制御部と、ファイル転送プロトコルのようなSMTP POPメールプロトコルとしてFTPであります
  • 没有启动延迟确认应答(即接收数据后立刻返回确认应答)是无法实现捎带应答的
  • 因为捎带必须等待应用程序处理完数据并将作为回执的数据返回时才能进行捎带 哈哈哈

他のトランスポート層プロトコル P218

• UDP-Liteの
• SCTP
• DCCP
• 等

UDP-Liteの

• しかし現実には、いくつかのアプリケーションでは、このような状況に直面して低下した受信UDPベースの通信とパケットエラーはすべて破棄表示されますテストする必要はありません
• テストセットとUDPは、データの一部が、パッケージ全体の破壊が無駄にしません場合でも無効であるが、それはIPヘッダのIPアドレスが損傷または破壊されている場合、このメソッドは良くない、とされている場合は、ポート番号は、重大な結果を持つことができますので、
• 为了解决这些问题 UDP-Lite出现了
• 適用範囲によって制御されるUDP-Liteのチェックサム計算自体は、このような機構を有していてもよいです可以只针对不允许发生错误的部分进行校验和的价差

UDPフォーマット

これは何も言わないように

TCPフォーマット

TCP中没有包长度和数据长度的字符串

• TCPデータ送信部を表すオフセットデータは、TCPパケットの部分は、TCPヘッダ長官がされた最初から理解されるべきです
• 控制位 8位大小 每一位都有其意义 P223
• 紧急指针只有在URG控制位为1时有效 P225
• 可选项 P225

TCP UDP疑似ヘッダチェックサムを計算します