计算机网络

应用层 提供应用程序接口 SMTP,FTP,HTTP,NFS,telnet, dns,X.500
表示层 处理数据格式、数据加密等特定的功能
会话层 简历、维护和管理会话
传输层 建立主机端到端的可靠链接 TCP UDP
网络层 寻址和路由选择 IP X.25 Ethernet
数据链路层 提供介质访问、链路管理等 SDLC HDLC PPP STP 帧中继
物理层 比特流传输
对等实体在一次交互作用中传送的信息单位称为协议数据单元，它包括控制信息和用户数据两部分，上下层实体之间的接口称为服务访问点*SAP，网络层的服务访问点也称为网络地址*，通常分为网络号和主机地址。

A类IP段　1.0.0.0 到126.255.255.255 (0段和127段不使用)
B类IP段　128.0.0.0 到191.255.255.255
C类IP段　192.0.0.0 到223.255.255.255

A类的默认子网掩码　255.0.0.0　一个子网最多可以容纳1658万多台电脑
B类的默认子网掩码　255.255.0.0　一个子网最多可以容纳6万台电脑
C类的默认子网掩码　255.255.255.0　一个子网最多可以容纳254台电脑

子网掩码只有一个作用，就是将某个IP地址划分成网络地址和主机地址两部分。
子网掩码由1和0组成，且1和0分别连续。子网掩码的长度也是32位，左边是网络位，用二进制数字“1”表示，1的数目等于网络位的长度；右边是主机位，用二进制数字“0”表示，0的数目等于主机位的长度。这样做的目的是为了让掩码与ip地址做按位与运算时用0遮住原主机数，而不改变原网络段数字，而且很容易通过0的位数确定子网的主机数（主机号全为1时表示该网络广播地址，全为0时表示该网络的网络号，这是两个特殊地址）

传输中的包，未达到终点不能重组，但可以分散成碎片。
网络阻塞会导致丢包

端口
端口号的范围是0-65535，知名端口0-1023
80：用于浏览网页HTTP服务
21：ftp服务
22：ssh
23：telnet
25：SMTP
53：DNS端口
135：RPC(远程过程调用)
443：https
8080：代理端口
8000和4000：qq

ping
ping命令用来测试网络连通状态，使用ICMP(Internet control message protocol,网络控制消息协议)，他是TCP/IP协议的一个子协议，用于在IP主机、路由器之间传递控制消息，，跟踪路由的tracert命令也是基于ICMP协议的。
ICMP数据包尺寸不能chaoguo64kb，“ping of death“：如果ICMP数据包的尺寸烧过64KB时，主机就会出现内存分配错误，到时TCP/IP堆栈奔溃，导致主机死机。
ICMP风暴：向目标主机长时间、连续、大量的发送ICMP数据包，使目标主机耗费大量CPU资源处理，也会最终使系统瘫痪

TCP三次捂手，四次挥手
TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:

位码即tcp标志位,有6种标示:

• SYN(synchronous建立联机)
• ACK(acknowledgement 确认)
• PSH(push传送)
• FIN(finish结束)
• RST(reset重置)
• URG(urgent紧急)
• Sequence number(顺序号码)
• Acknowledge number(确认号码)

过程

• 第一次握手：建立连接，客户端发送SYN包(syn=j)到服务器，并进入SYN_SENT状态，等待服务器确认。
• 第二次握手：服务器收到SYN包，必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k)，即SYN+ACK包，此时服务器进入SYN_RCVD状态。
• 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1),此包发送完毕，客户端和服务器端进入ESTABLISHED状态，完成三次握手。客户端和服务器开始传输数据。
  挥手：
• 第一次挥手：客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送。
• 第二次挥手：服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。
• 第三次挥手：服务器B关闭与客户端A的连接，发送一个FIN给客户端A。
• 第四次挥手：客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。

三次握手阶段：ack等于上一次syn+1
四次挥手阶段：ack等于上一次fin+1
TCP协议的连接是全双工连接，一个TCP连接存在双向的读写通道。
简单说来是 “先关读，后关写”，一共需要四个阶段。以客户机发起关闭连接为例：
1.服务器读通道关闭
2.客户机写通道关闭
3.客户机读通道关闭
4.服务器写通道关闭
第一阶段 客户机发送完数据之后，向服务器发送一个FIN数据段，序列号为i；
- 1.服务器收到FIN(i)后，返回确认段ACK，序列号为i+1，关闭服务器读通道；
- 2.客户机收到ACK(i+1)后，关闭客户机写通道；
（此时，客户机仍能通过读通道读取服务器的数据，服务器仍能通过写通道写数据）
第二阶段 服务器发送完数据之后，向客户机发送一个FIN数据段，序列号为j；
- 3.客户机收到FIN(j)后，返回确认段ACK，序列号为j+1，关闭客户机读通道；
- 4.服务器收到ACK(j+1)后，关闭服务器写通道。

参数说明
服务端收到建立连接的SYN没有收到ACK包的时候处在SYN_RECV状态，这时候有两个参数：
1.synack_retries：内核在放弃连接之前所送出的 SYN+ACK 数目，保证TCP连接不要因为偶尔的丢包而无法建立。
2.tcp_syncookies：防止SYN Flood攻击，处在SYNC_RECV的TCP连接称为半连接，并存储在内核的半连接队列中，在内核收到对端发送的ack包时会查找半连接队列，并将符合的requst_sock信息存储到完成三次握手的连接的队列中，然后删除此半连接。大量SYNC_RECV的TCP连接会导致半连接队列溢出，这样后续的连接建立请求会被内核直接丢弃，这就是SYN Flood攻击。在TCP服务器收到TCP SYN包并返回TCP SYN+ACK包时，不分配一个专门的数据区，而是根据这个SYN包计算出一个cookie值。在收到TCP ACK包时，TCP服务器在根据那个cookie值检查这个TCP ACK包的合法性。如果合法，再分配专门的数据区进行处理未来的TCP连接。

timeout时间，半连接存活时间，是指半连接队列的存活最长时间，即服务从收到SYN包到确认这个报文无效的最长时间，该时间值是所有重传请求包的最长等待时间总和。

关闭链接阶段
CLOSE_WAIT：发起TCP连接关闭的一方称为client，被动关闭的一方称为server。被动关闭的server收到FIN后，但未发出ACK的TCP状态是CLOSE_WAIT。出现这种状况一般都是由于server端代码的问题，如果你的服务器上出现大量CLOSE_WAIT，应该要考虑检查代码。
TIME_WAIT：发起socket主动关闭的一方 socket将进入TIME_WAIT状态。TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),在Windows下默认为4分钟，即240秒。TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接，将导致服务器端存在大量的处于TIME_WAIT状态的socket， 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力，甚至耗尽可用的socket，停止服务。

1. 三次握手建立连接时，发送方再次发送确认的必要性？
   主 要是为了防止已失效的连接请求报文段突然又传到了B,因而产生错误。假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结 点长时间滞留了，一直延迟到连接释放以后的某个时间才到达B，本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次 新的连接请求，于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了，这样一直等待A发来数据，B的许多 资源就这样白白浪费了。
2. 四次挥手释放连接时，等待2MSL的意义？
   第 一，为了保证A发送的最有一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN和ACK 报文段的确认。B会超时重传这个FIN和ACK报文段，而A就能在2MSL时间内收到这个重传的ACK+FIN报文段。接着A重传一次确认。
   第二，就是防止上面提到的已失效的连接请求报文段出现在本连接中，A在发送完最有一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。
3. 常见的应用中有哪些是应用TCP协议的，哪些又是应用UDP协议的，为什么它们被如此设计？
   以下应用一般或必须用udp实现？
   多播的信息一定要用udp实现，因为tcp只支持一对一通信。
   如果一个应用场景中大多是简短的信息，适合用udp实现，因为udp是基于报文段的，它直接对上层应用的数据封装成报文段，然后丢在网络中，如果信息量太大，会在链路层中被分片，影响传输效率。
   如果一个应用场景重性能甚于重完整性和安全性，那么适合于udp，比如多媒体应用，缺一两帧不影响用户体验，但是需要流媒体到达的速度快，因此比较适合用udp
   如果要求快速响应，那么udp听起来比较合适
   如果又要利用udp的快速响应优点，又想可靠传输，那么只能考上层应用自己制定规则了。
   常见的使用udp的例子：ICQ,QQ的聊天模块。