目录
2.传输层 （segment数据段）传输层加上头部后的PDU变成了数据段
2^16 2的16次方个端口号 （因为16个比特能表示出2^16=65536个数字）
TCP是一个可靠的传输，UDP是个不可靠的传输，那么具体TCP可靠在哪里呢？？
nonono，在进行确认时，确认号=上一个报文的序列号+应用层字节数大小=a+1+127+200+数据字节，这个数据字节=发来的三条数据的数据字节数之和，也就是说最终
在TCP报文里有个窗口字段，他用来告诉对端，本端在同一时段，最多能接收的字段。
一、常见协议标准化组织
二、TCP/IP各层的协议
1.应用层（PDU协议数据单元）
Telnet现在几乎不用了，因为不支持加密，在输入密码远程登录的时候，输入的密码，通过抓包可以看到，故使用Telnet不安全。
2.传输层 （segment数据段）传输层加上头部后的PDU变成了数据段
1）传输层
2）TCP和UDP-报文格式
只要是TCP的协议，那么必定有这个TCP头部（20字节）
UDP同理，但是UDP的头部通常是6-8字节，因为有点UDP包没有checksum（校验和）
（1）源目端口号（16bit）
16bit能表示多少个端口号呢？
2^16 2的16次方个端口号 （因为16个比特能表示出2^16=65536个数字）
端口号的取值范围为0-65535
通常我们在访问服务器的时候，我们重点关注的是去往的目的地址、目的端口号，
所以源端口号取值范围1024-65535内随机产生（因为不知道随机产生的是哪个端口号，也称为了未知端口号）。
而目标端口号是我们要访问的服务，而这些服务的端口号是固定好的，取值范围为1-1023，例如http-80，ftp-21等，所以也称之为已知端口号。
（2）序列号和确认号（32bit）
TCP是一个可靠的传输，UDP是个不可靠的传输，那么具体TCP可靠在哪里呢？？
答案就是：序列号和确认号了，有一个通讯回馈机制
比方说，上课时老师经常会问我们，同学们听懂了没？我们就会回馈（听懂了/没听懂）
虽然UDP没有TCP可靠，但是他也有他的优点，因为不用得到回馈，他只管发包，不管其他人是否接收到，丢包就丢包，所以在实时的直播中会经常用到。（给我的感觉udp像大佬一样“我说我的，管你们听不听，我只管发包，其他的我不管哈哈哈”）（tcp就是“我发了包，你必须给我回馈，否则我就认为这个包丢了”）
虽然说TCP可靠，但是该丢的包还是会丢，但是与UDP不同的是，TCP丢包能发现他丢了（因为没有得到回馈）
（3）控制位（6bit）
控制位有6个bit 就是说有6个0
000000 每个bit都有一个相应的功能，当开启这个功能的时候，0会置位为1
3）三次握手
seq为序列号，ack为确认号
三次握手之后，开始传数据，序列号沿用上一次确认的序列号
上一个报文是指上一个对方发来的报文
序列号=上一个报文的确认号
确认号=上一个报文的序列号+应用层字节数大小
确认号既保证收到对方的报文，有保证将对方报文完完整整收到
TCP每条报文都在做确认，确认对方发来的最后一条
如图，TCP传输数据不一定是一条一条传的，有可能是一次传输多条数据
那么，在进行确认的时候，序列号=上一个报文的确认号 =b+1+0+10
确认号=上一个报文的序列号+应用层字节数大小=a+1+127+200+？？
在这里就会有疑问，发来的三条数据有data=20、30、40的，那么确认时，确认号也要分开确认吗？？
nonono，在进行确认时，确认号=上一个报文的序列号+应用层字节数大小=a+1+127+200+数据字节，这个数据字节=发来的三条数据的数据字节数之和，也就是说最终
ack=a+1+127+200+20+30+40
4）TCP的窗口滑动机制
TCP传输数据时，不是传的越多越好，而是更有效率更好
比如，传送100条数据，而对端只能收90个，就必定有10个包会被丢掉，而TCP传输机制是丢1个包，全部重发，就造成了很多不便。
所以这个TCP窗口滑动机制就能有效解决这一问题，控制数据传输的数据。
在TCP报文里有个窗口字段，他用来告诉对端，本端在同一时段，最多能接收的字段。
经过两端的协商，可以在对端最大接收范围内尽可能的传输最多的数据，这样就保证了，既不会浪费资源，也不会导致包的丢失。
为什么pc1所发的报文的窗口字段没有变化呢？
因为，pc1的处理速度如果够快，在相同时段，已经讲对端发来的数据处理完了，那么他的字段不变
上图其实是有问题的，因为每个数据包携带的数据是1个字节，所以seq应该是上一条对方发来的ack，也就是说这pc1发送的三条数据的seq=101，而最后pc2对三条数据确认时，ack=101+1+1+1=101
扫一扫
561
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
