黑客从入门到超神！！！
NTML验证：Windows系统的验证方式
不安全的文件（执行顺序如下）：.com,.exe,.bat，.vbs
打开.doc .xls .ppt 等微软类型邮件时，需进行杀毒
UXSS针对浏览器进行攻击
注意：不要在浏览器上报错账号信息 在手机应用商店上进行下载软件（手机识别码权限，电话权限可以给手机软件）
手机木马：消灭星星、listenService、库柏市场等
社会工程学建议：1.保护个人信息不外泄 2.时刻提高警惕3.不乱丢废物
常规漏洞介绍、环境搭建说明
肉鸡
木马：用于窃取数据或者监控操作
网页木马
挂马（通过浏览器漏洞远程下载执行）
后门
IPC$ 共享管道通信
shell 壳：一种终端，例如CMD
webshell：脚本（asp、aspx、php、jsp、cgi）,webshell管理工具：菜刀
溢出（缓冲区溢出）：堆溢出、栈溢出，超出输入限制边界、导致后面代码被执行。
注入:(sql注入、进程注入)
进程：lsass.exe 登陆认证
内网LAN（10.0.0.0~10.255.255.255；172.16.0.0~172.31.255.255；192.168.10.0~192.168.255.255）
127.0.0.1回环地址/保留地址
外网WLAN（）
CVE:（common vulnerabilities explosures）常见漏洞披露
EXP:攻击功能的代码
POC:测试是否有漏洞的代码
PAYLOAD:病毒通常会做一些有害的或者恶性的动作。在病毒代码中实现这个功能的部
分叫做“有效负载”。payload可以实现任何运行在受害者环境中的程序所能做的事情，并且能够执行动作包括破坏文件删除文件，向病毒的作者或者任意的接收者发送敏感信息，以及提供通向被感染计算机的后门。
NVD:国家漏洞数据库
CNNVD:中国漏洞数据库
0DAY:已存在，并未被官方打补丁，目前可以通杀。
1DAY
提权:通过之前的EXP等攻击进行提升权限
越权:水平越权 垂直越权：通过普通用户权限获得管理员权限
ATP:高级长期威胁
wpscan针对wordpress的收集，有几个用户、插件
端口
3389远程桌面
免杀
加壳（UPX,ASPack,PEPack,Upack,PECompack）：利用一些加密
花指令(汇编代码，令程序跳转不易被找到)
蠕虫病毒
嗅探（工具：Sniffer、Cain）
蜜罐（漏洞系统，模拟受害人，攻击手段搜集其系统）
输入法漏洞（主要针对微软智能ABC）
Unicode漏洞（主要针对IIS过滤不严格导致被绕过）
CGI漏洞（CGI脚本自身解析有远程执行风险）
SSL漏洞（HTTP上的加密措施，可被用户窃取证书、私钥、伪造）
IIS漏洞（主要是6.0、7.0等解析问题）
admin（administrators、NT版本的Windows上的主要管理员权限，SYSTEM>user>guest）
root(Linux用户的最高权限)
协议：
FTP（TCP）、TFTP(UDP)、HTTP（TCP）、ICMP
旁站入侵：同一服务器下的其他网站，跨目录（有权限前提）
C端入侵（B段入侵，110.110.110.1/24）
内网渗透（内网拓展，从一台机器拓展到目标机器）
社工
与数据库相关名词：
MSSQL:(Sa管理权限)
DBowner
public
root：MySQL的根（mysql，pg数据库）
dual：Oracle的一个表（Oracle）
相对路径（../../../etc/passwd）
FoFA
端口转发（利用中间可控服务器的正常端口如80，映射内网的反弹端口。工具：htran、lcx、、）
XML实体注入
搭建渗透测试环键
1.搭建一个IIS的运行环境
2.搭建一个PHP的运行环境
3.成功运行BurpSuit工具
4.wireshark成功抓取局域网数据包
<html>
<% = "hello"%>
<br>
<%response.write "hello"%>
</html>
<%@Page language="c#">
<%string a="hello"
Response.Write("hello");%>
<% Response.Write("hello");%>
访问共享文件， \\机子号\gx,通过file协议
00-50开头的网卡是虚拟设备的网卡
网络五元组
<目标IP：目标端口：数据包内容：本地IP：本地端口>
TCP <目标IP：目标端口：data：本地IP：本地端口>
TCP三次握手(Three-way Handshake)
三次握手的目的是连接服务器指定端口，建立TCP连接,并同步连接双方的序列号和确认号并交换
TCP 窗口大小信息.在socket编程中，客户端执行connect()时。将触发三次握手。
![黑客从入门到超神！！！ 随笔 第1张]( "黑客从入门到超神！！！ 随笔 第1张")
第一次握手:
客户端发送一个TCP的SYN标志位置1的包指明客户打算连接的服务器的端口，以及初始序号X,保存在包头的序列号(Sequence Number)字段里。
![黑客从入门到超神！！！ 随笔 第2张]( "黑客从入门到超神！！！ 随笔 第2张")
第二次握手:
服务器发回确认包(ACK)应答。即SYN标志位和ACK标志位均为1同时，将确认序号(Acknowledgement Number)设置为客户的I S N加1以.即X+1。
![黑客从入门到超神！！！ 随笔 第3张]( "黑客从入门到超神！！！ 随笔 第3张")
第三次握手.
客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1
![黑客从入门到超神！！！ 随笔 第4张]( "黑客从入门到超神！！！ 随笔 第4张")
SYN攻击
在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于Syn_RECV状态.当收到ACK后，服务器转入ESTABLISHED状态.
Syn攻击就是 攻击客户端 在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直 至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。
Syn攻击是一个典型的DDOS攻击。检测SYN攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击.在Linux下可以如下命令检测是否被Syn攻击
netstat -n -p TCP | grep SYN_RECV
一般较新的TCP/IP协议栈都对这一过程进行修正来防范Syn攻击，修改tcp协议实现。主要方法有SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短超时时间等.
但是不能完全防范syn攻击。
TCP 四次挥手
TCP的连接的拆除需要发送四个包，因此称为四次挥手(four-way handshake)。客户端或服务器均可主动发起挥手动作，在socket编程中，任何一方执行close()操作即可产生挥手操作。
![黑客从入门到超神！！！ 随笔 第5张]( "黑客从入门到超神！！！ 随笔 第5张")
参见wireshark抓包，实测的抓包结果并没有严格按手时序。我估计是时间间隔太短造成。
![黑客从入门到超神！！！ 随笔 第6张]( "黑客从入门到超神！！！ 随笔 第6张")
注意上面的字段标号地段和发送接收的内容序号，可能有个有错，记不住哪个了，后头要细看看
第二部分：补充tcp连接过程
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接，如图1所示。
(1) 第一次握手：建立连接时，客户端A发送SYN包(SYN=j)到服务器B，并进入SYN_SEND状态，等待服务器B确认。
(2) 第二次握手：服务器B收到SYN包，必须确认客户A的SYN(ACK=j+1)，同时自己也发送一个SYN包(SYN=k)，即SYN+ACK包，此时服务器B进入SYN_RECV状态。
(3) 第三次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK(ACK=k+1)，此包发送完毕，客户端A和服务器B进入ESTABLISHED状态，完成三次握手。
完成三次握手，客户端与服务器开始传送数据。
由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送(报文段4)。
（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1(报文段5)。和SYN一样，一个FIN将占用一个序号。
（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A(报文段6)。
（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1(报文段7)。
TCP采用四次挥手关闭连接如图2所示。
1．为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的连接请求后，它可以把ACK和SYN(ACK起应答作用，而SYN起同步作用)放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可能未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
2．为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？
这个问题可以参考《unix 网络编程》
TIME_WAIT状态由两个存在的理由。
（1）可靠的实现TCP全双工链接的终止。
这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。
（2）允许老的重复的分节在网络中消逝。
假 设在12.106.32.254的1500端口和206.168.1.112.219的21端口之间有一个TCP连接。我们关闭这个链接，过一段时间后在 相同的IP地址和端口建立另一个连接。后一个链接成为前一个的化身。因为它们的IP地址和端口号都相同。TCP必须防止来自某一个连接的老的重复分组在连 接已经终止后再现，从而被误解成属于同一链接的某一个某一个新的化身。为做到这一点，TCP将不给处于TIME_WAIT状态的链接发起新的化身。既然 TIME_WAIT状态的持续时间是MSL的2倍，这就足以让某个方向上的分组最多存活msl秒即被丢弃，另一个方向上的应答最多存活msl秒也被丢弃。 通过实施这个规则，我们就能保证每成功建立一个TCP连接时。来自该链接先前化身的重复分组都已经在网络中消逝了。
3. 为什么不能用两次握手进行连接？
我们知道，3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
补充：
a. 默认情况下(不改变socket选项)，当你调用close( or closesocket，以下说close不再重复)时，如果发送缓冲中还有数据，TCP会继续把数据发送完。
b. 发送了FIN只是表示这端不能继续发送数据(应用层不能再调用send发送)，但是还可以接收数据。
c. 应用层如何知道对端关闭？通常，在最简单的阻塞模型中，当你调用recv时，如果返回0，则表示对端关闭。在这个时候通常的做法就是也调用close，那么TCP层就发送FIN，继续完成四次握手。如果你不调用close，那么对端就会处于FIN_WAIT_2状态，而本端则会处于CLOSE_WAIT状态。这个可以写代码试试。
d. 在很多时候，TCP连接的断开都会由TCP层自动进行，例如你CTRL+C终止你的程序，TCP连接依然会正常关闭，你可以写代码试试。
插曲：
特别的TIME_WAIT状态：
从以上TCP连接关闭的状态转换图可以看出，主动关闭的一方在发送完对对方FIN报文的确认(ACK)报文后，会进入TIME_WAIT状态。TIME_WAIT状态也称为2MSL状态。
什么是2MSL？MSL即Maximum Segment Lifetime，也就是报文最大生存时间，引用《TCP/IP详解》中的话：“它(MSL)是任何报文段被丢弃前在网络内的最长时间。”那么，2MSL也就是这个时间的2倍。其实我觉得没必要把这个MSL的确切含义搞明白，你所需要明白的是，当TCP连接完成四个报文段的交换时，主动关闭的一方将继续等待一定时间(2-4分钟)，即使两端的应用程序结束。你可以写代码试试，然后用setstat查看下。
为什么需要2MSL？根据《TCP/IP详解》和《The TCP/IP Guide》中的说法，有两个原因：
其一，保证发送的ACK会成功发送到对方，如何保证？我觉得可能是通过超时计时器发送。这个就很难用代码演示了。
其二，报文可能会被混淆，意思是说，其他时候的连接可能会被当作本次的连接。直接引用《The TCP/IP Guide》的说法：The second is to provide a “buffering period” between the end of this connection and any subsequent ones. If not for this period, it is possible that packets from different connections could be mixed, creating confusion.
TIME_WAIT状态所带来的影响：
当某个连接的一端处于TIME_WAIT状态时，该连接将不能再被使用。事实上，对于我们比较有现实意义的是，这个端口将不能再被使用。某个端口处于TIME_WAIT状态(其实应该是这个连接)时，这意味着这个TCP连接并没有断开(完全断开)，那么，如果你bind这个端口，就会失败。对于服务器而言，如果服务器突然crash掉了，那么它将无法再2MSL内重新启动，因为bind会失败。解决这个问题的一个方法就是设置socket的SO_REUSEADDR选项。这个选项意味着你可以重用一个地址。
对于TIME_WAIT的插曲：
当建立一个TCP连接时，服务器端会继续用原有端口监听，同时用这个端口与客户端通信。而客户端默认情况下会使用一个随机端口与服务器端的监听端口通信。有时候，为了服务器端的安全性，我们需要对客户端进行验证，即限定某个IP某个特定端口的客户端。客户端可以使用bind来使用特定的端口。对于服务器端，当设置了SO_REUSEADDR选项时，它可以在2MSL内启动并listen成功。但是对于客户端，当使
用bind并设置SO_REUSEADDR时，如果在2MSL内启动，虽然bind会成功，但是在windows平台上connect会失败。而在linux上则不存在这个问题。(我的实验平台：winxp, ubuntu7.10)
要解决windows平台的这个问题，可以设置SO_LINGER选项。SO_LINGER选项决定调用close时TCP的行为。SO_LINGER涉及到linger结构体，如果设置结构体中l_onoff为非0，l_linger为0，那么调用close时TCP连接会立刻断开，TCP不会将发送缓冲中未发送的数据发送，而是立即发送一个RST报文给对方，这个时候TCP连接就不会进入TIME_WAIT状态。如你所见，这样做虽然解决了问题，但是并不安全。通过以上方式设置SO_LINGER状态，等同于设置SO_DONTLINGER状态。
断开连接时的意外：
这个算不上断开连接时的意外，当TCP连接发生一些物理上的意外情况时，例如网线断开，linux上的TCP实现会依然认为该连接有效，而windows则会在一定时间后返回错误信息。这似乎可以通过设置SO_KEEPALIVE选项来解决，不过不知道这个选项是否对于所有平台都有效。
第三部分：常见面试题
![黑客从入门到超神！！！ 随笔 第7张]( "黑客从入门到超神！！！ 随笔 第7张")
![黑客从入门到超神！！！ 随笔 第8张]( "黑客从入门到超神！！！ 随笔 第8张")
![黑客从入门到超神！！！ 随笔 第9张]( "黑客从入门到超神！！！ 随笔 第9张")
CLOSED: 表示初始状态。
LISTEN: 表示服务器端的某个SOCKET处于
监听状态，可以接受连接了。
SYN_RCVD: 表示接受到了SYN
报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的
三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端
测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。
SYN_SENT: 这个状态与SYN_RCVD遥相呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN
报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送
三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。
ESTABLISHED： 表示连接已经建立了。
FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN
报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。
FIN_WAIT_2： 上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。
TIME_WAIT: 表示收到了对方的FIN
报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
CLOSING: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN
报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也就会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN
报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是查看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。
LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN
报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。
第二天
一、操作系统安全
WINDOWS：http://msdn.itellyou.cn/ 下载操作Windows系统
calc 运行计算器 mstsc 远程桌面 regdeit注册表 两个老漏洞：
MS06014:适用于XP，不卡、不弹、不闪 MS08067
常用命令 /?详细信息
msinfo32 查看系统信息（图形化）
ver 命令行内查看系统版本
winver查看系统版本（图形化）
powershell 进入powershell环境
nslookup 根据域名反查对方
mstsc 远程桌面
path 查看环境变量内容，之间每个分号代表不同程序隔断
more 一屏一屏展示内容
手工查杀木马 ：netstat、nbtstat、reg、sc config、sc query、tasklist、taskkill
netstat -ano -p tcp -f
-r查看路由表 -p指定协议 -f查看本机与外部地址的通信状态
-b 显示在创建每个连接或侦听端口时涉及的可执行程序。在某些情况下，已知可执行程序承载多个独立的组件，这些情况下，显示创建连接或侦听端口涉及的组件序列。在此情况下，可执行程序的名称位于底部 [] 中，它调用的组件位于顶部，直至达到 TCP/IP。
nbtstat
-c 列出远程[计算机]名称及其 IP 地址的 NBT 缓存
-a 列出指定名称的远程机器的名称表
-A 列出指定 IP 地址的远程机器的名称表。
-n 列出本地 NetBIOS 名称。
-r 列出通过广播和经由 WINS 解析的名称
-R 清除和重新加载远程缓存名称表
-S 列出具有目标 IP 地址的会话表
-s 列出将目标 IP 地址转换成计算机 NETBIOS 名称的会话表。
-RR 将名称释放包发送到 WINS，然后启动刷新
REG 注册表 key键 subkey子键 branch 分支 （value entry)值
HKCR
HKCU 存放当前登录用户个人个性化喜好设置、所用软件的设置等数据。无论谁都可以修改属于自己个人的注册表数据
HKLM 本地机器系统全局配置自键与用户无关
HKCC 所有会话的配置信息
HKU 所有用户配置
reg add keyName [{/v ValueName | /ve}] [/t DataType] [/s Separator] [/d Data] [/f] 将新的子项或项添加到注册表中 1）开启3389端口： REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Terminal" "Server /v fDenyTSConnections /t REG_DWORD /d 00000000 /f 2）关闭3389端口： REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Terminal" "Server /v fDenyTSConnections /t REG_DWORD /d 11111111 /f
windows消息驱动、注册表提取要被打开的文件程序路径（假若无路径，提取一串注册表地址）
sc服务操作
sc query 服务名称 - 显示 eventlog 服务的状态 （服务名称在service.msc中可查看）
sc queryex eventlog - 显示 eventlog 服务的扩展状态， 多了一个PID
sc config 在注册表和服务数据库中修改服务项（选项名称包括等号）
扫码关注我们
微信号：SRE实战
拒绝背锅 运筹帷幄
- TCP协议和UDP协议的区别是什么
- TCP协议是有连接的，有连接的意思是开始传输实际数据之前TCP的客户端和服务器端必须通过三次握手建立连接，会话结束之后也要结束连接。而UDP是无连接的
- TCP协议保证数据按序发送，按序到达，提供超时重传来保证可靠性，但是UDP不保证按序到达，甚至不保证到达，只是努力交付，即便是按序发送的序列，也不保证按序送到。
- TCP协议所需资源多，TCP首部需20个字节（不算可选项），UDP首部字段只需8个字节。
- TCP有流量控制和拥塞控制，UDP没有，网络拥堵不会影响发送端的发送速率
- TCP是一对一的连接，而UDP则可以支持一对一，多对多，一对多的通信。
- TCP面向的是字节流的服务，UDP面向的是报文的服务。
- TCP介绍和UDP介绍
- 请详细介绍一下TCP协议建立连接和终止连接的过程？
- 建立连接：三次握手
- 关闭连接：四次挥手
- 三次握手建立连接时，发送方再次发送确认的必要性？
- 主 要是为了防止已失效的连接请求报文段突然又传到了B,因而产生错误。假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结 点长时间滞留了，一直延迟到连接释放以后的某个时间才到达B，本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次 新的连接请求，于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了，这样一直等待A发来数据，B的许多 资源就这样白白浪费了。
- 四次挥手释放连接时，等待2MSL的意义？
- 第 一，为了保证A发送的最有一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN和ACK 报文段的确认。B会超时重传这个FIN和ACK报文段，而A就能在2MSL时间内收到这个重传的ACK+FIN报文段。接着A重传一次确认。
- 第二，就是防止上面提到的已失效的连接请求报文段出现在本连接中，A在发送完最有一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。
- 常见的应用中有哪些是应用TCP协议的，哪些又是应用UDP协议的，为什么它们被如此设计？
- 以下应用一般或必须用udp实现？
- 多播的信息一定要用udp实现，因为tcp只支持一对一通信。
- 如果一个应用场景中大多是简短的信息，适合用udp实现，因为udp是基于报文段的，它直接对上层应用的数据封装成报文段，然后丢在网络中，如果信息量太大，会在链路层中被分片，影响传输效率。
- 如果一个应用场景重性能甚于重完整性和安全性，那么适合于udp，比如多媒体应用，缺一两帧不影响用户体验，但是需要流媒体到达的速度快，因此比较适合用udp
- 如果要求快速响应，那么udp听起来比较合适
- 如果又要利用udp的快速响应优点，又想可靠传输，那么只能考上层应用自己制定规则了。
- 常见的使用udp的例子：ICQ,QQ的聊天模块。
- 以qq为例的一个说明
- 等号和值之间需要一个空格
- 要删除依赖关系，请使用单个“/”表示依赖关系值。
更多精彩
