使用IP协议就能把源主机A发送出的分组按照首部中的目的地址，交送到目的主机B，为什么还需要运输层呢？
IP数据报的首部明确地标志了这两台主机的IP地址，但两台主机之间的通信的实体是主机中的进程，IP协议可以把分组送到目的主机但是不知道要交付到哪个应用上去。分组就停留在主机的网络层而没有交付主机中的进程。
为什么要制定端口？
计算机操作系统种类多，不同操作系统使用不同格式的进程标识符，为了是他们能够互相通信，就必须用统一的方法对TCP/IP体系的应用进程进行标志。
说白了就是为了确定一种统一的协议来方便不同操作系统进程之间的通信。
常用的应用层协议有哪些？分别对应的是什么传输层协议？
| 应用层协议 | 传输层协议 | 应用 | 端口号 |
|---|---|---|---|
| HTTP协议 | TCP | 万维网 | 80 |
| FTP简单邮件传输协议 | TCP | 文件传送 | 21 |
| SMTP简单邮件传输协议 | TCP | 25 | |
| Telnet远程终端协议 | TCP | 23 | |
| SNMP简单网络管理协议 | TCP | 161 | |
| DNS域名解析系统 | UDP | 53 | |
| TFTP | UDP | 69 | |
| IGMP网际管理协议 | UDP | 多播、流式多媒体通信 | |
| 专用协议 | UDP | Ip电话 |
传输层协议：
TCP和UDP属于传输层协议。
- UDP（用户数据报协议）
特点：
- 无连接的
- 尽最大努力交付
- 面对报文的。对应用层交下来的报文，在添加首部后就向下交付IP层
- 没有拥塞控制，主机恒定输出，允许丢包，不允许有太大时延
- 支持1对1，1对多，多对多，多对1通信
- 首部开销小->8歌字节
- TCP（传输控制协议）
2022.3.26更新
TCP特点
- 面向连接的
- 只能点对点
- 可靠交付,无差错,不丢失,不重复,按序到达
- 提供全双工通信,允许通信双方的应用进程在任何时候都能发送数据
- 面向字节流,虽然应用程序和TCP的交互是一次1个数据块,但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流.
TCP为什么是可靠的？
网络传输是尽最大努力交付，TCP采取了一些措施才能够实现通信可靠。例如:超时重传
1.停止等待协议：
停止等待协议就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
优：简单，容易实现
缺：信道利用率低
优化：流水线传输
停止等待处理的几种情况：
- 无差错情况：按照A发送，B接收确认，然后A再发送
- 出错情况：
a.A传给B M，B接收M时出错，B直接丢弃M，当A发送出去有一段时间没有接收到B的确认消息之后，就会进行超时重传。
b.A传给 B M时出错，B什么都不知道，也不会有任何动作。
有了停止等待协议，A超过一段时间没有收到确认就认为分组丢失了，会再次重传。
- 确认丢失和迟到：
A传给B，B再会送确认消息时丢失了M，A在设定的超时重传内没有收到消息。A在超时计时器到期后要重传M
a.B此时如果收到了重传的M丢弃这个重复的分组，不向上交付。
b.向A发送确认消息，防止再重传
c.A传给B时超时，A重传，B丢弃重复的M，重传确认M，此时A再收到B延迟的消息时丢弃。
2.流水线传输
基于流水线传输的有两种协议：连续ARQ和滑动窗口协议
ARQ：
发送方每收到一个方确认就向右移动1个分组,接收方采用累计确认的方式,对按需到达的最后一个分组发送确认表示已收到所有分组.
优点:容易实现,丢失之后不必重传,因为在接收方如果有丢失的,接收方只对已经接收到的分组发送确认消息,发送发无法知道丢失的几个包的消息,会自动进行重传.
缺点:发送方无法知道接收方已经正确收到了全部分组的消息.
滑动窗口协议:
发送方每发送一个分组,收到确认消息后就把窗口向前推进一位.
TCP可靠传输的实现:
- 以字节为单位的滑动窗口
- 超时重传时间的选择
报文每重传一次,就把超时重传时间增大一些,当不再发生报文重传时才根据超时重传时间公式计算.
- 选择确认SACK
会出现首部超出限制问题.
三次握手：
- A向B发起请求，此时B处于Listen状态，B创建TCB传输控制块，A也打开TCN,并且向B发出请求报文段，将首部SYN=1，同时选择一个初始化序号
seq=x，TCP客户端进入SYN-SEND，syn已发送状态 - B收到请求后，如同意连接，则向A发送确认：
SYN=1,ACK=1，确认号ack=x+1，将自己的序列号设置为y - 客户算收到B确认后，再向B确认:
ACK=1,确认号ack=y+1，自己的序列号seq=x+1
如果是确认消息则用对方发来的确认号+1，如果是自己的消息，发送完消息之后自己的序列号+1.
为什么需要三次握手？
假设一种情况A向B发送内容时，因为网络原因到B的时候是一个无效的连接请求报文段。
假设只有两次握手的情况，到B收到确认消息后，B就认为A可以发送消息了，但是此时A没有收到确认消息，确认超时后进行超时重传。
而此时B会认为A发送的是一个新的请求，对于之前的连接B会一直保持这个连接等待A发送数据，但是A由于没有获取到确认消息就不会向B发出数据，导致B的 资源浪费。
四次挥手
- A向TCP发出连接释放报文段，兵停下在发送数据，主动关闭TCP连接
FIN=1,seq=u，等于前面已传送过的数据的最后一个字节的序列号+1
A进入fin-wait-1终止等待1阶段，等待B的确认 - B收到释放报文后发出请求，若B有要发的东西，A就要接收
ack=u+1,seq=v,B进入到close-wair等待关闭阶段，此时TCP处于半关闭阶段 - A收到B的确认后，进入fin-wait-2停止等待2阶段，等待B发出释放报文段
- B若没有要发的了，进入last-ack状态，做最后确认
FIN=1,ack=u+1,seq=w+1 - ACK=1发出确认,ack=w+1，序列号u+1进入到time-wait阶段，
TCP会在经过一段时间之后进入到close阶段
为什么需要四次挥手？
网友评论