计算机网络，传输层

不仅是记录我的半吊子基础知识，也是一次再学习，不敢保证都对

前言

  前边我们已经大概了解了网络层的知识，现在我们来了解传输层的知识。
  我们知道TCP/IP体系的每一层有每一层的作用，那我们传输层是干什么的呢？学完网络层的时候我们就发现，实际上网络层IP协议已经实现了计算机与计算机之间的通信，IP数据报的头部明确标志了源地址和目的地址，那为什么还要传输层呢？
  这时候就需要通过几个例子来说明，比如我们访问远程MySQL的时候，仅仅连接MySQL就行了，服务器上的其他服务跟我们没有关系；又或者我们访问网站的时候，通过一个网址，访问Nginx或者Tomcat，但是其他服务，就跟我们没有关系了。
  MySQL是一个进程；Nginx是一个进程；Tomcat是一个进程；你用的软件与浏览器也是一个进程。我们发现，事实上用户能够感受到的是两个应用进程之间的通信。而传输层的作用就是提供两个应用进程之间的通信。
  根据应用程序的不同需求，传输层有两个不同的协议，即TCP协议与UDP协议。

UDP协议

  连接与无连接：举个常见的例子，我们要打电话，肯定要先拨通号码，对方接听之后才能对话，拨通电话的过程就是双方在建立连接。那么发短信就不一样了，不用管他能不能收到，直接发就行。对方因为欠费啊，没信号啊等等原因没收到就不管我们的事情了，我们想发就发。连接与无连接就好比是打电话与发短信。
  UDP就是无连接协议，不管对方能不能收到，只负责发送过去就行了。就这么简单，但是不可靠。
  报文，数据链路层传输的数据叫做帧，网络层传输的数据叫做数据报，而传输层传输的数据叫做报文。
  帧有头部和尾部，IP数据报有IP首部，UDP报文也有首部。IP数据报首部有源IP地址和目的IP地址，UDP首部有源端口号和目的端口号。

TCP协议

  该协议就比UDP复杂多了，它是面向连接的协议。就像打电话一样，有一个拨通建立连接的过程，通话结束再挂断的过程。它是可靠的传输协议，它的首部要复杂的多。
  可靠传输，如何保证可靠传输呢？我们来模拟一下，现在有接收方A和发送方B，B发送一个数据，A接收到了之后会给B发送一个确认消息，B收到确认消息之后才会继续发送数据，这个过程中，B等待A的确认消息，A等待B的数据。但是如果B发送数据之后，因为一些原因，A没有收到数据，或者A发送了确认但是B没有收到确认，B不能一直等待下去，所以等待一段时间之后B就会重新发送数据，这个过程叫做超时重传。这样就保证了数据的可靠传输。
  但是一个字节一个字节的发送数据效率太低，那我们一次就多发几个字节，比如这里有十个字节的数据{0,1,2,3,4,5,6,7,8,9}，我们规定一次发送五个字节，这样一次就把{0,1,2,3,4}发送过去，如果收到了确认信息，表示五个字节我都收到了，那就接着把后边的五个也发送过去。但是因为网络环境太复杂，中间出了差错，我只收到了0,1,2的确认消息怎么办呢？那就只能从3开始发送，把{3,4,5,6,7}这五个字节发送过去。这个过程叫做滑动窗口。有一个问题，比如我只收到了1,3的确认消息怎么办，0,2,4没收到确认消息，全部重传就感觉效率低下，于是大佬们就发明了选择重传，就是哪个没传过去就重新传哪个。
  流量控制。接收方收到数据之后，会发送一个确认消息，这个消息里其实也包含了下一次想让发送方给我发送多少字节的数据，通过这样的方式接收方就可以控制发送方发送数据的大小，达+到流量控制的效果。
  拥塞控制。道路会堵车，信道当然也会堵车，数据量太大，处理不过来就导致了拥塞，拥塞自然就触发了超时重传。那么怎么进行拥塞控制呢？就是控制数据的发送量，比如第一次我发送2个字节，收到确认消息，说明网络状况良好，下一次我就发送4个字节，再下一次就发送8个字节，成指数递增，当然它不可能无限的指数递增，总有一个阈值的。到了这个阈值的时候就不是指数递增了，而是一个一个的递增，每次发送的数据量增加1，试探性的递增。等发生了超时就立马再从2个字节开始指数递增，重复上述步骤。指数递增的过程叫做慢开始，达到阈值之后试探性递增叫做拥塞避免。

三次握手

  TCP建立连接的过程称作三次握手。假设现在有发送方A和接收方B，A先发送一个要建立连接的消息给B，这是第一次握手，B收到消息之后再给A发送一个确认消息，这是第二次握手，A收到确认消息之后就会再给B发送一个消息表示我收到了你的确认消息，这是第三次握手，这样A和B就建立了连接。接下来就是互相传递数据了。
  那么为什么要三次握手而不是两次握手呢？书上说是为了防止已失效的连接突然又传送到了B，因而产生错误。这是什么意思呢，就是说A发送一个连接请求，由于这个请求在网络中迷路了，导致A觉得超时了需要重传，B收到了重传的请求之后跟A建立连接，这时候上一个迷路的请求又突然找到路了发给了B，B就会跟A再次建立一个连接，要知道建立一次连接是要耗费资源的。所以两次握手容易造成建立多个连接导致资源的浪费甚至引发错误。
  三次握手就能避免上述问题，迷路的连接请求突然给了B，B发送一个确认信息给A，A就会发现这条信息已经失效了，不理会它，那B收不到A的确认消息就不会跟A再建立连接。
  还有一种说法：第一次握手是A给B发送消息，B收到消息之后就知道A发送能力是正常的；二次握手A收到了B的确认信息，A就知道B收到了消息并且还给我发送了确认表明B的接收能力和发送能力是正常的。这时候A只证明了自己的发送能力正常，B还不知道A的接收能力是不是正常，所以A需要再发送一个收到确认的消息来证明自己的接收能力是正常的，这样A、B双方都证明了自己的接收能力与发送能力是正常的，连接就能建立了。

四次挥手

  这是关闭TCP连接的过程，A先给B发送一个关闭连接的请求，这是第一次挥手，B发送一个确认消息，表示我收到了这个请求，这是第二次挥手，随后B也发送一个关闭连接的请求，这是第三次挥手，A收到B关闭连接的请求之后就给B发送一个消息表示你关闭吧，这是第四次挥手。B关闭连接，A等半天没有响应就知道了B已经关闭了连接，于是就把自己的连接也关闭了。