SSL叫安全套接层协议，是国际上最早用的，已成工业标准，但它的基点是商家对客户信息保密的承诺，因此有利于商家而不利于客户。
SET叫安全电子交易协议，是为了在互联网上进行在线交易时保证信用卡支付的安全而设立的一个开放的规范。因它的对象包括消费者、商家、发卡银行、收单银行、支付网关、认证中心，所以对消费者与商家同样有利。它越来越得到众人认同，将会成为未来电子商务的规范
近年来，IT业界与金融行业一起，推出不少更有效的安全交易标准。主要有：
(1) 安全超文本传输协议（S-HTTP）：依靠密钥对的加密，保障Web站点间的交易信息传输的安全性。
(2) 安全套接层协议（SSL协议：Secure Socket Layer)是由网景（Netscape）公司推出的一种安全通信协议，是对计算机之间整个会话进行加密的协议，提供了加密、认证服务和报文完整性。它能够对信用卡和个人信息提供较强的保护。SSL被用于Netscape Communicator和Microsoft IE浏览器，用以完成需要的安全交易操作。在SSL中，采用了公开密钥和私有密钥两种加密方法。
(3) 安全交易技术协议(STT：Secure Transaction Technology)：由Microsoft公司提出，STT将认证和解密在浏览器中分离开，用以提高安全控制能力。Microsoft将在Internet Explorer中采用这一技术。
(4) 安全电子交易协议（SET：Secure Electronic Transaction）：SET协议是由VISA和MasterCard两大信用卡公司于1997年5月联合推出的规范。SET主要是为了解决用户、商家和银行之间通过信用卡支付的交易而设计的，以保证支付信息的机密、支付过程的完整、商户及持卡人的合法身份、以及可操作性。SET中的核心技术主要有公开密匙加密、电子数字签名、电子信封、电子安全证书等。
目前公布的SET正式文本涵盖了信用卡在电子商务交易中的交易协定、信息保密、资料完整及数字认证、数字签名等。这一标准被公认为全球网际网络的标准，其交易形态将成为未来“电子商务”的规范。
支付系统是电子商务的关键，但支持支付系统的关键技术的未来走向尚未确定。安全套接层（SSL）和安全电子交易（SET）是两种重要的通信协议，每一种都提供了通过Internet进行支付的手段。但是，两者之中谁将领导未来呢？SET将立刻替换SSL吗？SET会因其复杂性而消亡吗？SSL真的能完全满足电子商务的需要吗？我们可以从以下几点对比作管中一窥：
SSL提供了两台机器间的安全连接。支付系统经常通过在SSL连接上传输信用卡卡号的方式来构建，在线银行和其他金融系统也常常构建在SSL之上。虽然基于SSL的信用卡支付方式促进了电子商务的发展，但如果想要电子商务得以成功地广泛开展的话，必须采用更先进的支付系统。SSL被广泛应用的原因在于它被大部分Web浏览器和Web服务器所内置，比较容易被应用。
SET和SSL除了都采用RSA公钥算法以外，二者在其他技术方面没有任何相似之处。而RSA在二者中也被用来实现不同的安全目标。
SET是一种基于消息流的协议，它主要由MasterCard和Visa以及其他一些业界主流厂商设计发布，用来保证公共网络上银行卡支付交易的安全性。SET已经在国际上被大量实验性地使用并经受了考验，但大多数在Internet上购的消费者并没有真正使用SET。
SET是一个非常复杂的协议，因为它非常详细而准确地反映了卡交易各方之间存在的各种关系。SET还定义了加密信息的格式和完成一笔卡支付交易过程中各方传输信息的规则。事实上，SET远远不止是一个技术方面的协议，它还说明了每一方所持有的数字证书的合法含义，希望得到数字证书以及响应信息的各方应有的动作，与一笔交易紧密相关的责任分担。
. SSL安全协议
SSL安全协议最初是由Netscape Communication公司设计开发的，又叫“安全套接层（Secure Sockets Layer）协议”，主要用于提高应用程序之间的数据的安全系数。SSL协议的整个概念可以被总结为：一个保证任何安装了安全套接字的客户和服务器间事务安全的协议，它涉及所有TC/IP应用程序。
SSL安全协议主要提供三方面的服务：
用户和服务器的合法性认证
认证用户和服务器的合法性，使得它们能够确信数据将被发送到正确的客户机和服务器上。客户机和服务器都是有各自的识别号，这些识别号由公开密钥进行编号，为了验证用户是否合法，安全套接层协议要求在握手交换数据进行数字认证，以此来确保用户的合法性。
加密数据以隐藏被传送的数据
安全套接层协议所采用的加密技术既有对称密钥技术，也有公开密钥技术。在客户机与服务器进行数据交换之前，交换SSL初始握手信息，在SSL握手情息中采用了各种加密技术对其加密，以保证其机密性和数据的完整性，并且用数字证书进行鉴别。这样就可以防止非法用户进行破译。
护数据的完整性
安全套接层协议采用Hash函数和机密共享的方法来提供信息的完整性服务，建立客户机与服务器之间的安全通道，使所有经过安全套接层协议处理的业务在传输过程中能全部完整准确无误地到达目的地。
要说明的是，安全套接层协议是一个保证计算机通信安全的协议，对通信对话过程进行安全保护。例如，一台客户机与一台主机连接上了，首先是要初始化握手协议，然后就建立了一个SSL。对话进段。直到对话结束，安全套接层协议都会对整个通信过程加密，并且检查其完整性。这样一个对话时段算一次握手。而HTTP协议中的每一次连接就是一次握手，因此，与HTTP相比。安全套接层协议的通信效率会高一些。
（1）接通阶段：客户通过网络向服务商打招呼，服务商回应；
（2）密码交换阶段：客户与服务器之间交换双方认可的密码，一般选用RSA密码算法，也有的选用Diffie-Hellmanf和Fortezza-KEA密码算法；
（3）会谈密码阶段：客户与服务商间产生彼此交谈的会谈密码；
（4）检验阶段：检验服务商取得的密码；
（5）客户认证阶段：验证客户的可信度；
（6）结束阶段，客户与服务商之间相互交换结束的信息。
当上述动作完成之后，两者间的资料传送就会加密，另外一方收到资料后，再将编码资料还原。即使盗窃者在网络上取得编码后的资料，如果没有原先编制的密码算法，也不能获得可读的有用资料。
发送时信息用对称密钥加密，对称密钥用非对称算法加密，再把两个包绑在一起传送过去。
接收的过程与发送正好相反，先打开有对称密钥的加密包，再用对称密钥解密。
在电子商务交易过程中，由于有银行参与，按照SSL协议，客户的购买信息首先发往商家，商家再将信息转发银行，银行验证客户信息的合法性后，通知商家付款成功，商家再通知客户购买成功，并将商品寄送客户。
SSL安全协议是国际上最早应用于电子商务的一种网络安全协议，至今仍然有很多网上商店使用。在传统的邮购活动中，客户首先寻找商品信息，然后汇款给商家，商家将商品寄给客户。这里，商家是可以信赖的，所以客户先付款给商家。在电子商务的开始阶段，商家也是担心客户购买后不付款，或使用过期的信用卡，因而希望银行给予认证。SSL安全协议正是在这种背景下产生的。
SSL协议运行的基点是商家对客户信息保密的承诺。但在上述流程中我们也可以注意到，SSL协议有利于商家而不利于客户。客户的信息首先传到商家，商家阅读后再传至（银行，这样，客户资料的安全性便受到威胁。商家认证客户是必要的，但整个过程中，缺少了客户对商家的认证。在电子商务的开始阶段，由于参与电子商务的公司大都是一些大公司，信誉较高，这个问题没有引起人们的重视。随着电子商务参与的厂商迅速增加，对厂商的认证问题越来越突出，SSL协议的缺点完全暴露出来。SSL协议将逐渐被新的电子商务协议（例如SET）所取代。
[page]
11. SET安全协议
在开放的因特网上处理电子商务，保证买卖双方传输数据的安全成为电子商务的重要的问题。为了克服SSL安全协议的缺点，满足电子交易持续不断地增加的安全要求，为了达到交易安全及合乎成本效益的市场要求，VISA国际组织及其它公司如Master Card、Micro Soft、IBM等共同制定了安全电子交易（SET：Secure Electronic Transactions）公告。这是一个为在线交易而设立的一个开放的、以电子货币为基础的电子付款系统规范。SET在保留对客户信用卡认证的前提下，又增加了对商家身份的认证，这对于需要支付货币的交易来讲是至关重要的。由于设计合理，SET协议得到了许多大公司和消费者的支持，己成为全球网络的工业标准，其交易形态将成为未来“电子商务”的规范。
安全电子交易规范，为在因特网上进行安全的电子商务提供了一个开放的标准。SET主要使用电子认证技术，其认证过程使用RS
主要特点：面向连接、面向字节流、全双工通信、通信可靠。
优缺点：
应用场景：要求通信数据可靠时，即 数据要准确无误地传递给对方。如：传输文件：HTTP、HTTPS、FTP等协议；传输邮件：POP、SMTP等协议
ps：首部的前 20 个字节固定，后面有 4n 字节根据需要增加。故 TCP首部最小长度 = 20字节（最大60个字节）。
TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。
重要字段：
客户端与服务器来回共发送三个TCP报文段来建立运输连接，三个TCP报文段分别为：
（1）客户端A向服务器B发送的TCP请求报段“SYN=1,seq=x”；
（2）服务器B向客户端A发送的TCP确认报文段“SYN=1,ACK=1,seq=y,ack=x+1”；
（3）客户端A向服务器B发送的TCP确认报文段“ACK=1,seq=x+1,ack=y+1”。
ps：在建立TCP连接之前，客户端和服务器都处于关闭状态（CLOSED）,直到客户端主动打开连接，服务器才被动打开连接（处于监听状态 = LISTEN）,等待客户端的请求。
TCP 协议是一个面向连接的、安全可靠的传输层协议，三次握手的机制是为了保证能建立一个安全可靠的连接。
通过上述三次握手， 双方确认自己与对方的发送与接收是正常的，就建立起一条TCP连接，即可传送应用层数据 。ps：因 TCP提供的是全双工通信，故通信双方的应用进程在任何时候都能发送数据；三次握手期间，任何1次未收到对面的回复，则都会重发。
为什么两次握手不行呢 ？
结论：防止服务器接收了 早已经失效的连接请求报文 ，服务器同意连接，从而一直等待客户端请求， 最终导致形成死锁、浪费资源 。
ps：SYN洪泛攻击：（具体见下文）
为什么不需要四次握手呢 ？
SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK确认序号标志消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。
如何来解决半连接攻击？
如何来解决全连接攻击？
请注意 ，现在 TCP 连接还没有释放掉。必须经过 时间等待计时器 设置的时间 2MSL（MSL：最长报文段寿命）后，客户端才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果服务器一收到 客户端的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，服务器结束 TCP 连接的时间要早于客户端。
TCP是全双工的连接，必须两端同时关闭连接，连接才算真正关闭。 简言之，客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器才会发送 FIN 连接释放报文，对方确认后就完全关闭了TCP连接。
举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。
ps：设想这样一个情景： 客户端已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。 显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用 TCP的保活计时器 。基本原理：
tcp11种状态及变迁其实基本包含在正常的三次握手和四次挥手中，除开CLOSING。
正常的三次握手包括4中状态变迁：
服务器打开监听(LISTEN)->客户端先发起SYN主动连接标识->服务器回复SYN及ACK确认->客户端再确认即三次握手TCP连接成功。这里边涉及四种状态及变迁：
正常的四次握手包含6种tcp状态变迁，如主动发起关闭方为客户端：
客户端发送FIN进入FIN_WAIT1 ->服务器发送ACK确认并进入CLOSE_WAIT(被动关闭)状态->客户端收到ACK确认后进入FIN_WAIT2状态 ->服务器再发送FIN进入LAST_ACK状态 ->客户端收到服务器的FIN后发送ACK确认进入TIME_WAIT状态 ->服务器收到ACK确认后进入CLOSED状态断开连接 ->客户端在等待2MSL的时间如果期间没有收到服务器的相关包，则进入CLOSED状态断开连接。
CLOSING状态 ：连接断开期间，一般是客户端发送一个FIN，然后服务器回复一个ACK，然后服务器发送完数据后再回复一个FIN，当客户端和服务器同时接受到FIN时，客户端和服务器处于CLOSING状态，也就是此时双方都正在关闭同一个连接。
在进入CLOSING状态后，只要收到了对方对自己发送的FIN的ACK，收到FIN的ACK确认就进入TIME_WAIT状态，因此，如果RTT(Round Trip Time TCP包的往返延时)处在一个可接受的范围内，发出的FIN会很快被ACK从而进入到TIME_WAIT状态，CLOSING状态持续的时间就特别短，因此很难看到这种状态。
我们知道网络层，可以实现两个主机之间的通信。但是这并不具体，因为，真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机， 但是并没有交付给主机的具体应用进程 。而 端到端的通信才应该是应用进程之间的通信 。
应用场景 ：UDP协议比TCP协议的效率更高，TCP协议比UDP协议更加安全可靠。
下面主要对 数据传输出现错误/无应答/堵塞/超时/重复 等问题。
注意：TCP丢包：TCP是基于不可靠的网路实现可靠传输，肯定会存在丢包问题。如果在通信过程中，发现缺少数据或者丢包，那边么 最大的可能性是程序发送过程或者接受过程中出现问题。
总结：为了满足TCP协议不丢包，即保证可靠传输，规定如下：
注意：TCP丢包有三方面的原因，一是网络的传输质量不好，二是安全策略，三是服务器性能瓶颈
先理解2个基础概念：发送窗口、接收窗口
工作原理：
注意点：
关于滑动窗口的知识点：
滑动窗口中的数据类型：
ARQ解决的问题：出现差错时，让发送方重传差错数据：即 出错重传
类型：
流量控制和拥塞控制解决的问题：当接收方来不及接收收到的数据时，可通知发送方降低发送数据的效率：即 速度匹配
流量控制 ：
注意：
拥塞控制 ：
慢开始与拥塞避免 ：
快重传和快恢复 ：
补充：流量控制和拥塞控制的区别
什么情况造成TCP粘包和拆包？
解决TCP粘包和拆包的方法：
传输层无法保证数据的可靠传输 ，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。
最简单的方式是在应用层模仿传输层TCP的可靠性传输。 下面不考虑拥塞处理，可靠UDP的简单设计。
https://www.jianshu.com/p/65605622234b
http://www.open-open.com/lib/view/open1517213611158.html
https://blog.csdn.net/dangzhangjing97/article/details/81008836
https://blog.csdn.net/qq_30108237/article/details/107057946
https://www.jianshu.com/p/6c73a4585eba
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）