网络基础2-TCP/IP相关

2017-04-07 本文已影响35人 Shirley_y

IP相关

IP：Internet Protocol网际协议，作用与TCP/IP模型中的互联网层，也就是OSI中的网络层。作用为实现端对端的连接，可实现不同数据链路的连接（数据链路层仅能实现相同数据链路的连接，而网络层可跨越不同数据链路）。

首先明确IP属于面向无连接型协议，即传输数据时并不会先确定是否已经建立起了源主机与目标主机的连接，而是直接发送数据包，这就导致了在目标主机关机或不存在时，数据无法正常送达，由此产生了冗余的通信，但IP采用无连接的方式目的在与简化数据传输过程与加快传输速度。（若要实现可靠地面向连接的传递，则由上层的TCP来实现）

IP地址知识：

IP地址=网络地址+主机地址
网络地址即为同一网段的标识，主机地址不允许在同一网段（即同一网络地址）下重复。由此保证在相互连接的整个网络中每台主机的IP地址都不会重复，即IP地址就具有了唯一性（但IP地址是有限的，具体的解决方案后文再详述）。
IP地址分为A，B，C，D四类
如下图所示：

IP地址.png

A类：0.0.0.0~127.0.0.0，后24位为主机标识位，由于网络地址中0和127的被保留，可用的网络地址为2^{7-2=126个，同理，主机地址中全0与全1的也为保留地址，所以每个网络地址可分配2}24-2=16777214个主机地址
B类：128.0.0.0~191.255.0.0，后16位为主机标识位，与A类的计算方法一样，由于前两位必须为10，所以网络地址有2^{14-2=16382个，每个网络地址可分配2}16-2=65534个主机地址
C类：192.0.0.0~223.255.255.0，后8位为主机标识位，与A类的计算方法一样，由于前三位必须为110，所以网络地址有2^{21-2=2097150个，每个网络地址可分配2}8-2=254个主机地址
D类：224.0.0.0~239.255.255.255，无主机标识，常被用于多播

提高IP地址利用率的两种方式：

子网掩码：
根据上诉四类IP地址的分类，不难看出分类的其实并不合理，比如B类网络地址同一链路上最多可连接65534台主机，这几乎是不会发生的，所以这对于网络地址来说是很浪费的，更别说A类资源了，所以，通过一个“子网掩码”方式来实现对网络地址的进一步划分。
子网掩码有两种表现形式：
A：当做32位2进制数表示，网络地址部分全为“1”，主机部分全为“0”
如：IP地址：192.40.102.60
子网掩码：255.255.255.192
网络地址：192.40.102.0
广播地址为：192.40.102.63
B：用“/”+位数表示
如：IP地址：192.40.102.60 /26
网络地址：192.40.102.0 /26
广播地址为：192.40.102.63 /26
但是，当我有一个区域的网络，主机不需要连接外网时，此时的IP地址若通过上诉两种方式来分又浪费了，所以，又出现了私有地址与全局地址的概念。
私有地址：
A类：10.0.0.0~10.255.255.255 （10/8）
B类：172.16.0.0~172.31.255.255（172.16/12）
C类：192.168.0.0~192.168.255.255（192.168/16）
以上范围内的地址均属于私有地址，在此之外的地址为全局地址。即公司可为每台主机分配私有地址，再在对外服务器上设置全局地址（配有私有地址的主机连接外网时，通过NAT协议实现）。这样，全局地址必须保持唯一性，而私有地址则只保证在同一域内唯一就可以了，不同域内的私有地址互不影响，这样就很大程度上解决了IPv4地址的有限的分配问题。而全局地址则需要向专门的机构申请（ICANN）。

IP分割处理与再构成处理

每种数据链路不同，其最大传输单元（MTU）也不同，例如FDDI的最大MTU为4352，而以太网的MTU为1500，所以大小为4000的IP数据报可以在FDDI中传输却无法在以太网中传输，路由器就承担了分割作用，将IP数据报分割成一帧能传输的最大单位，再由目的主机进行重组。路由器只会分片不会重组。（原因：路由器分组的数据也许会到达下一路由器，若此时重组，则还会面临分组的可能，降低了网络传送效率，所以仅在目标主机处进行重组）

路径MTU发现：

发送主机首先将IP报文的分片禁止位置为1，意思是不允许分片。当途径的路由器无法处理这么大的数据包时将其丢弃，并返回发送主机一个目标不可达的ICMP消息。此消息中包含了数据链路上的MTU值，发送主机根据收到的这个ICPM将数据分片，如此反复，直到将数据分片为所经数据链路的最小MTU而能到达目标主机为止。

TCP详细与UDP对比（Transmission Control Protocol）：

UDP与TCP比较：
TCP面向连接，建立可靠连接，且有重发机制，顺序机制
UDP（User Datagram Protocol）面向无连接，传输前无需提前建立连接，无重发机制，传输高速，适用于对实时性要求较高的场合（如音视频传输）或传输数据较少，广播通信，限定于LAN等特定网络中的应用通信

**TCP/IP通信中不可或缺的四个要素为：源IP地址，目标IP地址，源端口号，目标端口号
**

什么是端口号？
端口号即表示程序地址，用来识别同一计算机中的不同程序，传输层协议通过端口号决定将数据传输给哪个应用层协议处理，如HTTP协议的端口号为80（也是默认端口号），ftp端口号为21

TCP连接状态变迁图（摘自TCP/IP详解卷1）：

TCP连接状态变迁图.png

根据这张状态时序图可看出客户端与服务器在什么时候发送何种指令后处于什么状态，根据粗线即可看出客户端的正常状态变迁，虚线则是服务器的正常状态变迁。要牢记TCP的原则，即TCP连接是全双工(即数据在两个方向上能同时传递)，因此每个方向必须单独地进行关闭。

实现可靠性传输要点：

1.序列号与ACK（positive acknowledgement）（确认应答）：发送方发送数据序列号，接收方收到数据后返回ACK消息与已收到序列号的下一个数据序列号（未收到的序列号则不发）

2.重发控制：等待超时则重发数据，它是一个动态变化的时间。这个时间总是略大于连接往返时间（RTT，Round Trip Time）

3.连接管理：一个连接的建立与断开至少需要7个包来完成，如下图所示

TCP连接建立与断开.png

4.MSS（Maximum Segment Size）最大消息长度，三次握手时取出最小值放入TCP首部

5.窗口控制：每次发送端以窗口大小为单位发送一串数据吗，并在发送端主机建立了缓冲区，来放置未收到确认信号可能重发的数据，直到收到确认信号，再将此数据清除。收到确认应答后，窗口就滑动到了确认ack中返回的序号处，就可以实现多段数据同时发送来提高通信速度，这也称为滑动窗口控制。

6.窗口控制与（高速）重发控制：若发送端连续三次收到同一序列号的应答，则认为此数据丢失，重发此数据
情况一：目标主机未收到应该收到的数据时，例如本该收到下一数据为1001-2000，但却收到了2001-3000的数据，证明1001-2000数据已丢失，此时需要源主机重发，目标主机就应答1001的ack信号，当源主机连续收到三个该信号时，重发1001-2000的数据。
情况二：目标主机收到数据，但应答信号半路丢失，例如1001的ack丢失了，目标主机下一接收到的数据为1001-2000，此时目标主机正常应答2001的ack，源主机虽然未收到1001的ack，但由于已经确认目标主机收到了2001的ack，所以不会重发数据，所以在窗口足够大时，丢失少量的确认应答信号也不会导致重发消息

7.流控制：当接收端主机处理不过来接收到的数据时，可能就将后续收到的数据直接丢弃，这就会导致发送端的数据重发，为了避免这种浪费流量的情况，发送端需要时不时的发送窗口探测数据段，探测接收端缓冲区状态，以此来改变发送端的窗口大小

8.拥塞控制：连接刚建立时，发送主机并不知道接收端缓冲窗口的大小，此时若发送大量的数据，则可能会造成网络过载导致网络瘫痪，这时需要采用慢启动算法类控制窗口（也叫拥塞窗口cwnd（congestion window））大小。慢启动算法与拥塞避免算法：慢启动时将拥塞窗口初始值设置为1，以后每收到一个ACK则拥塞窗口值加1，如发送方开始时发送一个报文段，然后等待ACK。当收到该ACK时，拥塞窗口从 1 增加为 2 ，即可以发送两个报文段。当收到这两个报文段的ACK时，拥塞窗口就增加为4。发送数据前将拥塞窗口与接收端主机通知的窗口大小作比较，取较小值，发送比这个值小的数据量，但是，随着数据的成功发送，拥塞窗口的值成1，2，4的2的指数倍增长，也会导致数据激增的想象出现，所以又出现了慢启动门限（ssthresh）的概念：当拥塞窗口大于这个ssthresh值时，采用拥塞避免算法，拥塞避免算法要求每次收到一个确认时将cwnd增加1/cwnd。与慢启动的指数增加比起来，这是一种加性增长( additivein crease)。如下图所示：

拥塞窗口控制.png

假设ssthresh设置为16，网络正常返回所有的ack时，时间点1，发送端收到1个ack，将cwnd置为2，时间点2，发送端收到2个ack，将cwnd设置为4，时间点3，发送端收到4个ack，将cwnd设置为8，时间点4，发送端收到8个ack，将cwnd置为16，此时到达门限值，将不再使用慢启动算法，改用拥塞避免算法，时间点5，发送端收到16个ack，将cwnd增加16x1/16=1，即cwnd置为17，时间点6，发送端收到17个ack，将cwnd增加17x1/17=1，即cwnd置为18，后面的就依照线性增长。

窗口大小与吞吐量：
设窗口大小为W，往返时间为RTT
最大吞吐量Tmax=W/RTT bps

为什么建立TCP连接需要三次握手而不是2次或4次？（下列回答摘自网络）

回答1： TCP的三次握手最主要是防止已过期的连接再次传到被连接的主机。
谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ACK包。
简单点说就是：
如果采用两次的话，会出现下面这种情况。
比如是A机要连到B机，结果发送的连接信息由于某种原因没有到达B机；
于是，A机又发了一次，结果这次B收到了，于是就发信息回来，两机就连接。传完东西后，断开。结果这时候，原先没有到达的连接信息突然又传到了B机，于是B机发信息给A，然后B机就以为和A连上了，这个时候B机就在等待A传东西过去。

回答2：三次握手改成仅需要两次握手，死锁是可能发生
考虑计算机A和B之间的通信，假定B给A发送一个连接请求分组，A收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A认为连接已经成功地建立了，可以开始发送数据分组。可是，B在A的应答分组在传输中被丢失的情况下，将不知道A是否已准备好，不知道A建议什么样的序列号，B甚至怀疑A是否收到自己的连接请求分组。在这种情况下，B认为连接还未建立成功，将忽略A发来的任何数据分组，只等待连接确认应答分组。而A在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
然而，A在发送之后也有超时等待，当等待B的回应信号时间过长时也会重新发送SYN，所以并不一定出现死锁。

**我的理解：
世界上不存在完全可靠的通信协议，三次握手只是为了证明双方的收发都是可以的，但不排除其中出现某一方的收发有问题的情况发生，三次握手是最少的连接，为了确认也可以不同的重复发送。首先请求方发送SYN请求连接时证明了请求方有发送数据的能力，接收方接收后回发ACK+SYN证明了接收方有接收数据的能力与发送数据的能力，最后发送方收到接收方的反馈并发送ack，证明了发送方有接收数据的能力，所以三次握手是最少的能进行双向通信的保障。
**

为什么TCP协议终止连接要四次？

TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力，也称为半关闭特性
1、当主机A确认发送完数据且知道B已经接受完了，想要关闭发送数据口（当然确认信号还是可以发），就会发FIN给主机B。
2、主机B收到A发送的FIN，表示收到了，就会发送ACK回复。
3、但这是B可能还在发送数据，没有想要关闭数据口的意思，所以FIN与ACK不是同时发送的，而是等到B数据发送完了，才会发送FIN给主机A。
4、A收到B发来的FIN，知道B的数据也发送完了，回复ACK， A等待2MSL以后，没有收到B传来的任何消息，知道B已经收到自己的ACK了，A就关闭链接，B也关闭链接了。