携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第14天，点击查看活动详情 1. 当应用程序使用面向连接的TCP和无连接的IP时，这种传输是面向连接的还是面向无连接的？
都说，在运输层来看是面向连接的，在网络层来看是无连接的
2. 试举例说明有些应用程序愿意采用不可靠的UDP，而不采用可靠的TCP
类似爱奇艺的视频软件，流量大，信息有一定冗余度，出差所的数据包直接抛弃，人的感官分辨不出来，反之如果不同UDP，采用TCP的话出错全部重发，会导致时延，反而影响体验；qq聊天也是采用UDP，节约资源，通过容错机制降低了错报率，实际几乎不影响，反之如果使用TCP的话，服务端会接收海量连接，每个连接要维持一个连接，占用很多资源；
3. 如果应用程序愿意使用UDP来完成可靠的传输，这可能吗？
可以，需要添加一些协议已达到可靠传输的目的，比如qq
4. 端口的作用？
是对TCP/IP体系的应用进程进行统一的标志，使运行不同操作系统的计算机的应用进程能够互相通信。
5. 某个应用进程使用运输层的用户数据报UDP，然后继续向下交给IP层后，又封装成IP数据包。既然都是数据报，跳过UDP而直接交给IP层？哪些功能UDP提供了但IP没提供？
肯定不可以跳过UDP直接交给IP层的，IP数据包承担主机寻址功能，可以找到目的主机而无法找到目的进程；UDP提供了对应用进程的复用和分用功能，以及提供对数据差分的差错检验
6. 在TCP的拥塞控制中，什么是慢开始，拥塞避免，快重传和快恢复算法？这里每一种算法各起什么作用？ “乘法减小”和“加法增大”各用在什么情况下?
慢开始： 在主机刚刚开始发送报文段时可先将拥塞窗口cwnd设置为一个最大报文段
MSS的数值。在每收到一个对新的报文段的确认后，将拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送端的拥塞窗口cwnd，可以分组注入到网络的速率更加合理。
拥塞避免：当拥塞窗口值大于慢开始门限时，停止使用慢开始算法而改用拥塞避免算法。拥塞避免算法使发送的拥塞窗口每经过一个往返时延RTT就增加一个MSS的大小。
快重传算法规定：发送端只要一连收到三个重复的ACK即可断定有分组丢失了，就应该立即重传丢手的报文段而不必继续等待为该报文段设置的重传计时器的超时。
快恢复算法：当发送端收到连续三个重复的ACK时，就重新设置慢开始门限ssthresh与慢开始不同之处是拥塞窗口cwnd不是设置为1，而是设置为ssthresh若收到的重复的AVK为n个（n>3），则将cwnd设置为ssthresh若发送窗口值还容许发送报文段，就按拥塞避免算法继续发送报文段。若收到了确认新的报文段的ACK，就将cwnd缩小到ssthresh
乘法减小：是指不论在慢开始阶段还是拥塞避免阶段，只要出现一次超时（即出现一次网络拥塞），就把慢开始门限值ssthresh设置为当前的拥塞窗口值乘以0.5。当网络频繁出现拥塞时，ssthresh值就下降得很快，以大大减少注入到网络中的分组数。
加法增大：是指执行拥塞避免算法后，在收到对所有报文段的确认后（即经过一个往返时间），就把拥塞窗口cwnd增加一个MSS大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞
7. 试用具体例子说明为什么在运输连接建立时要使用三次握手。说明如不这样做可能会出现什么情况
3次握手完成两个重要的功能，既要双方做好发送数据的准备工作（双方都知道彼此已准备好），也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。 假定B给A发送一个连接请求分组，A收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A认为连接已经成功地建立了，可以开始发送数据分组。可是，B在A的应答分组在传输中被丢失的情况下，将不知道A是否已准备好，不知道A建议什么样的序列号，B甚至怀疑A是否收到自己的连接请求分组，在这种情况下，B认为连接还未建立成功，将忽略A发来的任何数据分组，只等待连接确认应答分组。而A发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
