目录
协议栈
OSI体系结果7层
- 应用层
- 表示层
- 会话层
- 运输层
- 网络层
- 数据链路层
- 物理层
TCP/IP体系结构 4层
- 应用层
- 运输层TCP/UDP
- 网际层IP
- 网络接口层
5层协议的体系结构
- 应用层
- 运输层
- 网络层
- 数据链路层
- 物理层
- 运输层
运输层为应用程序提供端到端的逻辑通信
Ip:Port
UDP
特点:
- 无连接
- 不保证可靠交付,尽最大努力交付,因此主机不需要维持复杂的连接状态表
- 面向报文的。应用层交给UDP多长的报文,UDP就照样发送,加上UDP首部就发送。
- UDP没有拥塞控制
- UDP支持一对一、一对多、多对一和多对多的交互通信
- UDP首部开销小,只有8个字节。
UDP首部格式
UDP首部由四个字段组成,每个字段的长度都是两个字节
- 源端口
- 目的端口
- 长度:UDP数据报的长度,首部加数据字段
- 检验和
没有IP的,IP是在网络层才加上的
TCP
特点
- 面向连接的运输层协议。使用TCP协议之前,需要先建立连接。
- TCP连接只能有两个端点,即点对点,一对一
- TCP提供可靠的服务,TCP保证传送的数据 无差错。不丢失、不重复、按序到达
- 全双工通信,允许通信双方在任何时候都能发送数据
- 面向字节流
可靠传输
TCP可靠传输以保证数据包不会丢失、失序、重复。
- 超时重传机制
就是发送方每发送出一个数据包就为该数据包启动一个计数器,如果超过了该时间设置还没有返回确认就重新发送该数据包。
(1)分组丢失:发送方发送分组,接收方没有收到分组,那么接收方不会发出确认,只要发送方过一段时间没有收到确认,就认为刚才的分组丢了,那么发送方就会再次发送.
(2):确认丢失:发送方发送成功,接收方接收成功,确认分组也被发送,但是分组丢失,那么到了等待时间,发送方没有收到确认,又会发送分组过去,此时接收方前面已经收到了分组,那么此时接收方要做的事就是:丢弃分组,重新发送确认.
(3):传送延迟:发送方发送成功,接收方接收成功,确认分组也被发送,没有丢失,但是由于传输太慢,等到了发送方设置的时间,发送方又会重新发送分组,此时接收方要做的事情:丢弃分组,重新发送确认. 发送方如果收到两个或者多个确认,就停止发送,丢弃其他确认.
自动请求
- 确认:接收方收到报文就会确认
- 数据校验:TCP报文头有校验和,用于校验报文是否损坏
- 数据合理分片和排序:tcp会按最大传输单元(MTU)合理分片,接收方会缓存未按序到达的数据,重新排序后交给应用层。
- 流量控制:当接收方来不及处理发送方的数据,能通过滑动窗口,提示发送方降低发送的速率,防止包丢失。
- 拥塞控制:当网络拥塞时,通过拥塞窗口,减少数据的发送,防止包丢失。
滑动窗口的重传协议
- 停等协议
停止等待协议是tcp保证传输可靠的重要途径,”停止等待”就是指发送完一个分组就停止发送,等待对方的确认,只有对方确认过,才发送下一个分组.
- 回退N步
接收方一般都是采用累积确认的方式。也就是说接收方不必对收到的分组逐个发送确认。而是在收到几个分组后,对按序到达的最后一个分组发送确认。如果收到了这个分组确认信息,则表示到这个分组为止的所有分组都已经正确接收到了。回退N步中丢失或发生错误的分组,及之后的的所有分组都需要全部重新发送,比如发送者发送了1-5号分组,而3号分组出现了问题,则3、4、5号分组都需要重传。
- 选择重传协议
在后退n协议中,接收方若发现错误帧就不再接收后续的帧,即使是正确到达的帧,这显然是一种浪费。另一种效率更高的策略是当接收方发现某帧出错后,其后继续送来的正确的帧虽然不能立即递交给接收方的高层,但接收方仍可收下来,存放在一个缓冲区中,同时要求发送方重新传送出错的那一帧。
- 连续ARQ协议(自动重传请求)
- 连续ARQ协议:它是指发送方维护着一个窗口,这个窗口中不止一个分组,有好几个分组,窗口的大小是由接收方返回的win值决定的,所以窗口的大小是动态变化的,只要在窗口中的分组都可以被发送,这就使得TCP一次不是只发送一个分组了,从而大大提高了信道的利用率.并且它采用累积确认的方式,对于按序到达的最后一个分组发送确认.
- 滑动窗口协议:之所以叫滑动窗口协议,是因为窗口是不断向前走的,该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认,因此该协议可以加速数据的传输,还可以控制流量的问题.
- 累积确认:如果发送方发送了5个分组,接收方只收到了1,2,4,5,没有收到3分组,那么我的确认信息只会说我期望下一个收到的分组是第三个,此时发送方会将3,4,5,全部重发一次,当通信质量不是很好的时候,连续ARQ还是会带来负面影响.
TCP报文段首部格式 !
尽量记住,不需要记长度
固定长度20字节,后面有4N字节根据需要而增加,可选
固定部分的字段:
- 源端口和目的端口,各占2字节
- 序号:4字节。TCP连接中传送的字节流中没一个字节都按顺序编号。该序号指的是本报文段所发送的数据的第一个字节的序号。
- 确认号:4字节,期望收到对方下一个报文段的第一个数据字节的序号。若确认号为N,则表示到序号N-1为止的所有数据都已正确收到。
- 数据偏移:4字节,实际上指的是TCP报文段首部的长度
- 保留字段,占6位
- 下面是6个控制位
- 紧急URG,该位置1,说明该报文段中有紧急数据,应尽快传送,优先级较高
- 确认ACK,仅当该位置1时,确认号字段才有效。TCP规定,连接建立后所有的传送报文段都必须将ACK置1
- 推送PUSH
- 复位RST
- 同步SYN,建立连接时用来同步序号。当SYN=1,ACK=0时,表明这是一个连接请求报文段。若对方同意建立连接,则响应报文段中SYN=1,ACK=1
- 终止FIN,用来释放连接。当FIN=1时,表明此报文段的发送方数据已发送完毕,并要求释放连接
- 窗口:占2字节。窗口指的是发送本报文段的一方的接收窗口(而不是自己的发送窗口)。窗口值告诉对方:从本报文段首部中的确认号算起,接收方目前允许对方发送的数据量。接收方的数据缓存空间是有限的,窗口值作为接收方让发送放设置其发送窗口的依据
- 检验和:2字节
- 紧急指针,在URG=1时才有意义
- 选项:长度可变,最多40字节。所以首部最多20+40字节
最大报文段长度MSS:MSS是每一个TCP报文段中数据字段的最大长度。
TCP实现流量控制
目的:让发送方的发送速率不要太快,让接受方来得及接收
发送方的发送窗口不能超过接收方给出的接收窗口的数值。TCP窗口单位是字节,而不是报文段。
A给B发送数据,其中窗口值表示的是当前A可以接受的字节数,即接收窗口的大小,而B收到报文段之后,会根据窗口值修改发送窗口的大小。窗口值是不断进行调整的。
TCP的拥塞控制(这一块看书:计算机网络第5版谢希仁版)
对网络中某一资源的需求超过了该资源所能提供的可用部分,网络性能就要变坏,这种情况就叫做拥塞
所谓拥塞控制就是 防止过多的数据注入到网络中,这样可以使网络中的路由器或链路不致过载。
流量控制是点到点的通信量控制,是端到端的问题。拥塞控制则是一个全局性的问题。
控制方法:
发送窗口维持一个叫做拥塞窗口的状态变量,拥塞窗口的大小取决于网络的拥塞程度,并且动态的变化。发送方让自己的发送窗口等于拥塞窗口。
只要发送方没有按时收到应当到达的确认报文,就可以猜想网络可能出现了拥塞。
为了方便,用报文段的个数作为窗口的大小单位。
1、慢开始
有小到大逐渐增大拥塞窗口的数值cwnd。首先设置为1,然后发送报文段M1,接收方收到后确认M1,然后把窗口设置为2,发送M2,M3,接收方收到后确认M2和M3,然后cwnd设置为4.每经过一个传输轮次,拥塞窗口就加倍。传输轮次指的是:把拥塞窗口的所允许的报文段都发出去,并收到了对已发送的最后一个字节的确认。
慢开始的“慢”指的不是增长速率慢,而是值刚开始设置为1,然后逐渐增大,而不是一下子增加到比较大的值。
为了防止cwnd增长过大引起网络拥塞,需要设置一个慢开始门限ssthresh的状态变量:
若cwnd < ssthresh:使用慢开始,每次翻倍的方式
若cwnd >ssthresh:停止使用慢开始而改用拥塞避免算法
若cwnd = ssthresh:即可使用。。。也可使用。。。
2、拥塞避免
思路是让拥塞窗口cwnd缓慢增大,即每经过一个传输轮次,cwnd加1,而不是加倍,这样cwnd按现行缓慢增长。
无论在慢开始 还是 拥塞避免阶段,如果发送发判断网络出现了拥塞,就把慢开始门限ssthresh设置为出现拥塞时发送放窗口值的一半,但不能小于2,然后拥塞窗口cwnd重新设置为1,执行慢开始算法。这样做得目的是 迅速减少主机发送到网络中的分组书,使得发送拥塞的路由器有足够的时间把队列中积压的分组处理完毕。
3、快重传
4、快恢复
三次握手和四次挥手(还是书上的)
会画图,记住每一步的状态变化!
三次握手:
步骤;
- A端TCP进程向B端发出连接请求报文段,首部中的同部位SYN=1,同时选择一个初始序列号seq=x。(TCP规定SYN报文段不能携带数据,但要消耗一个序号)此时A进入SYN_SENT状态
- B收到连接请求报文段后,若同意建立连接,则向A发送确认。在确认报文段将SYN位和ACK位都置1,确认号是ack=x+1。同时自己也选择一个初始序seq=y。此时B进入SYN_RCVD状态
- A收到B的确认后,还要向B给出确认。确认保卫段的ACK置1确认号ack=y+1。自己的序列号seq=x+1。这时A进入ESTABLISHED状态
- B收到A的确认后,也进入established状态
为什么需要三次握手?两次握手可以不?
四次挥手:
步骤
- A停止发送数据,并发送连接释放报文段、将连接释放报文段首部的FIN置1,其序号seq=u。这时A进入FIN_WAIT_1(终止等待1)状态。TCP规定,FIN报文段即使不携带数据,他也会消耗掉一个序号
- B收到连接释放报文段后,即发出确认。确认号是ack=u+1,报文段自己的序列号是seq=u,然后B进入CLOSE_WAIT(关闭等待)状态。此时TCP连接处于半关闭状态,即A已经没有数据要发送,但B若发送数据,A仍要接收。
- A收到B的确认后,进入FIN_WAIT_2(终止等待2),等待B发出的连接报文段。如果B没有要向A发送的数据,其应用进程就通知TCP释放连接。B发出连接释放报文段,FIN置1,。B需要重复上次已发送过的确认号ack=u+1。这时B进入LAST_ACK状态
- A收到B的释放连接报文段后,发出确认。确认号是ack=w+1。自己的序列号seq=u+1
为什么A在TIME-WAIT状态必须等待2MSL的时间?
MSL:最长报文段寿命。
- 保证A发送的最后一个ACK报文段能够到达B,因为这个报文段可能丢失,如果出在LAST-ACK状态的B收不到已发送FIN+ACK报文段的确认,B会超时重传这个FIN+ACK报文段,A在2MSL时间内收到这个崇川的报文段后会重传一次确认,并重启2MSL计时。如果A不等待,发送完确认立即释放连接的话,可能确认报文段丢失,没有传到B,此时B无法正常关闭。
- 如果Client直接CLOSED,然后又再向Server发起一个新连接,我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题,但是还是有特殊情况出现:假设新连接和已经关闭的老连接端口号是一样的,如果前一次连接的某些数据仍然滞留在网络中,这些延迟数据在建立新连接之后才到达Server,由于新连接和老连接的端口号是一样的,又因为TCP协议判断不同连接的依据是socket pair,于是,TCP协议就认为那个延迟的数据是属于新连接的,这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL,这样可以保证本次连接的所有数据都从网络中消失。
TCP的四种计时器
- 重传计时器
- 坚持计时器:解决0窗口通知而设立的
- 保活计时器:每当服务器收到客户的信息,就将keeplive timer复位,超时通常设置2小时,若服务器超过2小时还没有收到来自客户的信息,就发送探测报文段,若发送了10个探测报文段(没75秒发送一个)还没收到响应,则终止连接。
- 时间等待计时器:最后fin报文接收到后,发送ack,触发此计时器,等待两个MSL后断开连接,四次挥手结束。
详情见https://blog.csdn.net/xiaofei0859/article/details/52794576
应用层
常见的应用的协议:
电子邮件SMTP:tcp
远程终端访问Telnet:TCP
Web HTTP:tcp
文件传输FTP:tcp
流式多媒体HTTP:TCP
直播使用TCP好还是UDP好?为什么?
HTTP协议:
HTTP协议采用了请求/响应模型,浏览器或其他客户端发出请求,服务器给与响应。就整个网络资源传输而言,包括message-header和message-body两部分。首先传递message- header,即http header消息 。http header 消息通常被分为4个部分:general header, request header, response header, entity header。但是这种分法就理解而言,感觉界限不太明确。根据维基百科对http header内容的组织形式,大体分为Request和Response两部分。
HTTP头部
https://kb.cnblogs.com/page/92320/
https://www.jianshu.com/p/97e2a7a51505
- HTTP请求报文
由方法,URI,HTTP版本,HTTP头部字段等部分构成;
- HTTP响应报文
由HTTP版本,状态码,HTTP头部字段构成
- HTTP头部字段构成
- 通用头部字段(General Header Fields)
请求报文和响应报文都会使用的头部 - 请求头部字段(Request Header Fields)
补充请求的附加内容、客户端信息、响应内容相关优先级等; - 响应头部字段(Response Header Fields)
补充响应的附加内容 - 实体首部字段(Entity Header Fields)
针对实体部分使用的头部;补充资源内容的更新事件等;
浏览器根据输入的URL访问资源的过程???
https://blog.csdn.net/m_buddy/article/details/77800998
(1)域名解析:浏览器本身是一个客户端,当你输入URL的时候,首先浏览器会去请求DNS服务器,通过DNS获取相应的域名对应的IP
(2)然后通过IP地址找到IP对应的服务器后,(在80端口上)建立TCP连接
(3)浏览器发送完HTTP Request(请求)包后,服务器接收到请求包之后才开始处理请求包
(4)在服务器收到请求之后,服务器调用自身服务,返回HTTP Response(响应)包
(5)客户端收到来自服务器的响应后开始渲染这个Response包里的主体(body),等收到全部的内容随后断开与该服务器之间的TCP连接。
TCP相关时延对HTTP性能的影响,考虑一下: