计算机网络的传输层的简单介绍：

在应用层下为传输层，如TCP与UDP；

传输层与网络层之间的不一样： 传输层负责信息在主机进程与服务器进程之间的传递； 网络层负责信息在主机与服务器之间的传递；     差了一个进程啊；

传输层的信息用：segment 表示；它是这样获得的：把应用层的message 分红一块块，而后再加上传输层的文件头；

另外，TCP的信息也会用segment表示，UDP的信息用datagram（数据报）表示；网络层上的message也用datagram表示；

UDP：user datagram protocol; 它只会进行两个服务：1， 进程之间的数据交付；2，error checking;

TCP: transmission control protocol; 它进行的服务比较多，由于它是可靠传输；如：数据流控制等；

 

多路复用与多路分解：

因为传输层的做用是把信息交付给不一样的socket， 因此呢，在应用层与传输层之间须要用到了多路复用与多路分解；

多路复用指：不一样的socket的信息加入身份确认标志，通通变为为segment，而后用传输层交给了下面的网络层进行传送；

多路分解指：把不少segment交付给不一样的socket；

要求：1， 存在不一样的socket以及对应的端口；2， 每个segment上应该用用于identify的field，里面的信息为源端口与目的端口；

（补：端口的范围为0-65536，其中0-1023不能随便用，由于它是专用的，如HTTP等 或保留着呢，其它的能够随意用了；）

在一个传输层的segment中的用于识别的字段结构以下图，头占了8个字节：

 

无链接的多路利用/分解与面向链接的多路利用/分解

UDP的多路利用/分解：一个UDP socket使用目的主机的IP与目的主机的端口来肯定；

TCP的socket：由源IP、源端口、目的IP、目的端口来肯定；（一开始的握手segment除外）， 因此呢，TCP的socket能够有相同的端口，如WEB服务器的端口好像都是80吧（无故创建链接的socket仍是用于传输数据的socket）；

 

UDP：

很简单，它把应用层的数据加一个头就变为了UDP的segment. 它的segment的结构以下图所示：

它的头包括4个fields， 每个field的大小为：2字节；内容分别为： 源端口，目的端口，数据的长度和checksum(用于纠错）；

下面的application data，为应用层的数据；

 

可靠的传输：

问题1：如何解决发送的packet有误的问题？？

解决方法：版本1：当receive收到消息之后，就回复一个ACK（acknowledgment), 若是没有收到的消息出错了，就发送一个NAK，表示让发送者再从新发一遍；

              进级：为每个信息加一个sequence numbeer, 当收到的信息有误时，不发送该消息的NAK了，而是发送上一个收到的正确的消息的ACK;

问题2： packet在发送过程当中，若是Loss怎么办？

解决方法：加入消息重发机制； 当数据loss后，发送者确定就收不到ACK信息了， 加入一个计时器timer，超过必定的时间就重发；

问题3：如何提升传输的效率？

解决方法：采用流水线设计，具体为： go back N 和 selective repreat;

(里面有一些细节，省略不写，例如：要求未回应的信息的个数不大于N,等）

 

TCP：

它的结构以下图：

它的头，占了20个字节；

总的来看TCP， 

最主要的三点吧：

第一，如何进行可靠的传输，包括内容与顺序； 解决方法：对于错误的或loss的进行重传， 对于不是顺序的能够进行丢弃或缓存下来；

其中，怎么判断的问题：一个是timeout，一个是收到3个同一字段有ACK;   对于ACK，TCP采用的是accumulative 的方法，这一点很重要的；

另外的怎么计算timeout的时间啦，怎么重发等细节省略；

第二点：  对于如何解决flow 问题与confession问题，方法基本相同，就是控制发送方的rate（或窗口大小）, 可是二者的缘由不一样，一个是由于接收者上层应用接收的慢，一个是因为网络堵塞； 对于如何把出现上述缘由的状况反馈给发送者呢： 前者使用ACK信息里的的相应字段来解决；后者根据ACK到达发送者的状态，如loss了，仍是收到了3个多余的重复的ACK来判断，其中固然还有细节；

第三点： 如何使用流水线进行提升效率的问题：关键字：并行发，consequence number, ACK number, 还有一个发送窗口；

 

另外，对于三次握手的创建过程的原理，字段的做用等，也颇有意思；能够利用这个原理写端口扫描工具啦，进行网络攻击等；

 

 

 

###################      2017年9月补          ########################

1、 了解端口号：

1.了解端口号； 0-1023为周知端口号；

2. 一个UDP的套接字由目的IP地址与目的端口号来全面标识； TCP的套接字由源端口号、源IP地址、目的端口号、目的IP地址来识别；

3. 在这一层，数据常被称为报文段；

2、 UDP协议：

1. 使用DUP协议的例子：

2. UDP的报文段结构

如图所示：首部由4个字段组成，每一个字段2个字节；

长度：包括首部在内的所有的UDP的报文段长度，单位为字节；

3.

3、可靠数据传输：

一、 ARQ协议，自动重传请求协议；收到消息后，给一个应答来告诉是否收到了，收到回答ACK， 没有听清回答NAK；

2. 后来改进：加入了一个seq， 收到了就回答对应的seq,没有收到或收到错误的什么也不干， 由于加入了一个定时器，超时就重传；

3. 一个一个的传有点慢，采用了流水线的形式，而后，对于差错恢复问题的两个基本方法：GBN（回退N步）协议和SR（选择重传）协议；

  GBN协议：只要是否是按顺序到的分组，所有都丢弃； SR协议中则会缓存到一个地方；

4. 一个重的的控制传输多少个分组的：滑动窗口协议；

4、 TCP协议

1. TCP报文段对构：

 

32比特的序号与确认号： 

16比特的接收窗口：

4比特的首部长度：

可选与变长的选项字段：

6比特的标志字段：

• ACK：确认位，只有ACK=1的时候ack才起做用。正常通讯时ACK=1，第一次发起请求时由于没有须要确认接收的数据因此ACK为0。
• SYN：同步位，用于在创建链接时同步序号。刚开始简历链接时并无历史接收的数据，因此ack就没办法设置，这时按照正常的机制就没法运行了，SYN的做用就是来解决这个问题的，当接收端接收到SYN=1的报文时就会直接将ack设置为接收到的seq+1的值，注意这里的值并非校验后设置的，而是根据SYN直接设置的，这样正常的机制就能够运行了，因此SYN叫同步位。须要注意的是，SYN会在前两次握手时都为1，这是由于通讯的双方的ack都须要设置一个初始值。
• FIN：终止位，用来在传输数据完毕后释放链接。
• RST 置1时重建链接。若是接收到RST位时候，一般发生了某些错误。
• ACK 置1时表示确认号（为合法，为0的时候表示数据段不包含确认信息，确认号被忽略。
• PSH 置1时请求的数据段在接收方获得后就可直接送到应用程序，而没必要等到缓冲区满时才传送。
• URG（紧急位）: 急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。T C P的紧急方式是发送端向另外一端发送紧急数据的一种方式。紧急指针指向包内数据段的某个字节(数据从第一字节到指针所指字节就是紧急数据,不进入接收缓冲就直接交给上层进程,余下的数据要进入接收缓冲的)                           其中URG不能和PSH标志位同时使用，也对；由于紧急数据后面的要进缓冲区的；

16比特的紧急数据指针：用于指出紧急数据的最后一个字节位置；

TCP要传输的数据的最大值叫作最大报文段长(MSS); 它指的是最大的应用数据的长度， 不是包括TCP头部的最大TCP报文长度；MSS的大小受限于MTU；

 

2. TCP链接的创建与断开

创建链接：

 

断开链接：

 

3. TCP拥塞的控制：

参考这里： 写的很好;

  TCP/IP详解--拥塞控制 & 慢启动 快恢复 拥塞避免

 

 

参考：计算机网络第六版，自顶向下；