一、Protocol RM
1、OSI7层复杂复杂 PK TCP 3层简单
OSI每一层都要求可靠性,实现成本高,难获厂商支持。
TCP/IP没有OSI那么复杂,节省资源,没有OSI可靠。
2、TCP/IP上下层关联
应用层 | ←端口← | 传输层 |
传输层或应用层 | ←头标中Protocol字段← | 网络层 |
网络层 | →MAC地址→ | 物理层 |
二、IP Protocol
1、IP软件执行路由功能,为数据发送指定路径
2、IP Fragment and Reassembly (MTU长度取决于物理层协议)
每个路由器都要将接收到的帧进行拆包和处理,然后封装成另外一个帧。 |
IP数据报的尺寸大于将发往网络帧的MTU时,路由器将IP数据报分成若干较小分片。 |
数据报一旦被分片,则在到达目的主机之前就一直以单独的数据报存在,在到达主机后,才组合成原始的数据报,各个小的路由器可以独立路由,均衡负载。 |
当某个路由器认为一个设为Don't Fragment=1的数据报需要分片时,路由器放弃该数据报并向源主机发送一个出错消息。 |
三、ICMP,RFC792,1981
1、理解ICMP
IP收到差错或查询报文,交给IP软件的ICMP模块进行处理 |
IP层仅涉及与路径和可达相关的差错问题,而不解决数据本身的差错问题; |
ICMP报文是在IP数据报的数据段中传输的 |
ICMP差错报告采只向源主机报告差错原因; |
ICMP不能纠正差错,差错处理需要由高层协议去完成 |
2、Header Checksum(IP/ICMP/IGMP/TCP/UDP算法相同)
在发送端先计算校验和,并把得到的结果与分组一起发出去,同理,接收端检测结果,若正确则接收,反之丢弃。
三、Transfer Control Protocol
1、TCP基本特点
基于连接:3-wayHandshake(ConnectionOriented)+Four wave disconnect(Full Duplex) |
TCP确认机制、超时重发机制:TCP 可靠是因为它用序列号保证了传送数据包的顺序,响应包内也包括一个序列号J+1,表示希望发到下一个报文的编号从J+1开始。 |
流量控制机制:可变窗口 |
2、TCP state exchange(netstat –n –p tcp)
客:CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED |
服:CLOSED->LISTEN->SYN收到 ->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED |
3、TCP状态
LISTEN | 侦听来自远方的TCP端口的连接请求 |
SYN-SENT | 再发送连接请求后等待匹配的连接请求 |
SYN-RECEIVED | 再收到和发送一个连接请求后等待对方对连接请求的确认 |
ESTABLISHED | 代表一个打开的连接 |
FIN-WAIT-1 | 等待远程TCP连接中断请求,或先前的连接中断请求的确认 |
FIN-WAIT-2 | 从远程TCP等待连接中断请求 |
CLOSE-WAIT | 等待从本地用户发来的连接中断请求 |
CLOSING | 等待远程TCP对连接中断的确认 |
LAST-ACK | 等待原来的发向远程TCP的连接中断请求的确认 |
TIME-WAIT | 等待足够的时间以确保远程TCP接收到连接中断请求的确认 |
4、为什么建立连接是三次握手,而关闭连接却是四次握手呢?
在建立连接阶段:服务端收到SYN报文的建连请求后,它可以把ACK和SYN放在一个报文里来发送给客户端。
在关闭连接阶段:当收到对方的FIN报文通知时,仅表示对方没数据发送给你了;但未必你所有数据全发送给对方了,也即你可能还需要发送一些数据给对方之后,再发送FIN报文给对方来表示你同意现在可以关闭连接了,它的ACK报文和FIN报文多数情况下都是分开发送的。
三、UDP和TCP的对比(效率,可靠性)
比较项目 | TCP | UDP |
建立的连接与关闭 | 有 | 无 |
数据传输效率(网络可靠时) | 低 | 高 |
对数据的确认 | 有 | 无 |
流控机制 | 有(滑动窗口) | 无 |
丢失分组的重发 | 有 | 无(高层应用负责) |
协议复杂性 | 复杂 | 简单 |
发送端缓冲 | 有 | 无 |
分组排序 | 有 | 无 |
对重复分组的检测 | 有 | 无 |
校验和 | 有 | 有 |
在底层分片的情况 | 可能性小(建连接时双方通知各自MSS,每个TCP报文长度不超过MSS) | 可能性大(应用每次输出都产生一个UDP报文,当一次有大量数据要输出时常在底层被分片) |
广播与多播 | 不支持 | 支持 |
适用场合 | 可靠性要求高,有大量数据要连续传输,在互联网中应用多 | 可靠性要求一般,但要求高效传输,或用于数据传输量小的场合 |
四、NVT-ASCII(telnet,ftp,ssh,mail等)
五、SSH传输层、认证层和连接层)
连接建立 |
版本协商(1.x和2.x)、算法协商(3des,des-cbc) |
密钥交换(生成和交互数据的加解密密钥) |
用户认证 |
六、FTP Protocol
1、FTP使用Telnet协议进行控制连接
控制连接是user-PI和server-PI间用仅在发送命令并接收应答时使用的链路。控制端口用来监听双方共同规定的控制字。
2、数据连接(user-DTP和server-DTP传输链路)
主动模式客户端会侦听服务器以建立连接(适合FTP Server和client直接建立连接时使用) 命令连接请求:客户端 >1023端口 → 服务器 21端口 数据连接请求:客户端 >1023端口 ← 服务器 20端口 |
被动FTP对服务器端的管理不利(适合client位于防火墙之后的环境) 命令连接请求:客户端 >1023端口 → 服务器 21端口 数据连接请求:客户端 >1023端口 → 服务器 >1023端口 |
3、定义PASV端口范围(每个client占用一个Port)
Port号仅1个,有2个Client同时下载会失败
七、TFTP是一个很小且易于实现的文件传送协议
1、FTP的简化, 不支持交互, 不能身份鉴别, 只支持读/写传输
①发送完一个文件块后就等待对方的确认,确认时应指明所确认的块编号。 |
②发完数据后在规定时间内收不到确认就要重发数据PDU。 |
③发送确认PDU的一方若在规定时间内收不到下一个文件块,也要重发确认PDU。这样就可保证文件的传送不致因某一个数据报的丢失而告失败。 |
2、 基于UDP因此TFTP需要有自己的差错控制(表现为步锁)。
①客户进程发送一个读/写请求PDU给TFTP服务器进程,其熟知端口号码为69。 |
②服务器进程要选择一个新端口和TFTP客户进程进行通信。 |
③最后传送数据PDU的数据字段一定不满512字节,这正好可作为文件结束的标志。 |
④若文件长度为512B的整数倍,还必须在最后发送一个只含首部而无数据的数据PDU。 |
八、HTTP/1.1 Key Features(性能/安全/数据类型处理)
1、Content negotiation (DirectoryIndex index:cgi?html?)
2、多个request/response过程可以重叠进行
3、相比HTTP1.0增加了更多的请求头和响应头
4、长连接/keep-alive每次连接可处理多个请求。
长连接常用于P2P:多用于操作频繁,点对点的通讯,而且连接数不能太多的情况 |
短连接常用于一点对多点:像web网站这么频繁的成千上万甚至上亿客户端的连接用短连接更省一些资源。 |
5、MINEContent-Type允许HTTP传输任意类型的数据对象。
6、Statefull有状态的=(Stateless+cookie|session)
Cookie只保存ASCII;Session中可以存取任何类型的数据。 |
账号密码等尽量不要写到Cookie中。 |
Cookie长久地记录该用户的登录信息, 服务器累计的Session就会越多导致内存溢出。 |
服务器端的为每个用户都会产生一个Session。消耗大量的内存。 |
Session:只能在本浏览器窗口以及其子窗口内有效。如果两个浏览器窗口互不相干,它们将使用两个不同的Session。 |
WAP无Cookie,Session+URL地址重写也许是它唯一的选择。 |
Cookie支持跨域名访问,例如以“.ibm.com”为后缀的所有域名均可以访问该Cookie。 |
7、GET和POST区别如下
幂等:GET方式重复执行结果相同。 |
在用户刷新时:POST方式会弹出提示,问用户是否重新提交。 |
传送的数据量:GET方式数据量长度一般不超过2kb。 |
安全性:GET方式是直接将数据显示在地址栏中安全性低。 |
九、TLS是SSL 3.0的后续版本
1、Secure Sockets Layer(安全套接层协议)
SSL是一种在客户端和服务器端间建立安全通道的协议,它是跨越两层之间工作的特殊协议。它涉及所有TCP/IP应用程序。
SSL协议位于传输层的上层。而它自己也是一个分层协议。底层是SSL记录协议层,用于传输各种加密和认证信息;而SSL握手协议、SSL修改密文协议和SSL告警协议位于上层。
2、SSL连接(https)是对称/不对称加密的综合应用