1）SYN Flood 泛洪攻击 ： DDoS（分布式拒绝服务攻击）的方式之一。伪装的IP向服务器发送一个SYN请求建立连接，然后服务器向该IP回复SYN和ACK，但是找不到该IP对应的主机，当超时时服务器收不到ACK会重复发送。这种情况下服务器端一般会重试（再次发送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级（大约为30秒-2分钟）。当大量的攻击者请求建立连接时，服务器就会存在大量未完成三次握手的连接，为了维护一个非常大的半连接列表而消耗非常多的资源。
防范措施：
- 降低SYN timeout时间，使得主机尽快释放半连接的占用
- 采用SYN cookie设置，如果短时间内连续收到某个IP的重复SYN请求，则认为受到了该IP的攻击，丢弃来自该IP的后续请求报文
- 在网关处设置过滤，拒绝将一个源IP地址不属于其来源子网的包进行更远的路由
2）Land攻击(局域网拒绝服务攻击，Local Area Network Denial attack)，DDoS（分布式拒绝服务攻击）的方式之一。当一个主机向服务器发送SYN请求连接，服务器回复ACK和SYN后，攻击者截获ACK和SYN。然后伪装成原始主机继续与服务器进行通信 , 使目标机器开启一个源地址与目标地址均为自身IP地址的空连接，持续地自我应答，消耗系统资源直至崩溃。这种攻击方法与SYN洪泛攻击并不相同。
网络内尚未被确认收到的数据包数量 = 网络链路上能容纳的数据包数量 = 链路带宽 × 往返延迟
为了保证水管不会爆管，TCP 维护一个拥塞窗口cwnd（congestion window），用来估计在一段时间内这条链路（水管中）可以承载和运输的数据（水）的数量，拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化，但是为了达到最大的传输效率，我们该如何知道这条水管的运送效率是多少呢？
一个简单的方法就是不断增加传输的水量，直到水管破裂为止（对应到网络上就是发生丢包），用 TCP 的描述就是：
只要网络中没有出现拥塞，拥塞窗口的值就可以再增大一些，以便把更多的数据包发送出去，但只要网络出现拥塞，拥塞窗口的值就应该减小一些，以减少注入到网络中的数据包数。
常见的 TCP 拥塞控制算法
本文将例举目前 Linux 内核默认的 Reno 算法和 Google 的 BBR 算法进行说明，其中基于丢包的拥塞控制算法 Reno 由于非常著名，所以常常作为教材的重点说明对象。
Reno 被许多教材（例如：《计算机网络——自顶向下的方法》）所介绍，适用于低延时、低带宽的网络，它将拥塞控制的过程分为四个阶段：慢启动、拥塞避免、快重传和快恢复，对应的状态如下所示：
1.慢启动算法
如果在发送方和接收方之间存在多个路由器和速率较慢的链路时，就有可能出现一些问题。TCP支持一种被称为“慢启动 (slow start)”的算法。该算法通过观察到新分组进入网络的速率应该与另一端返回确认的速率相同而进行工作。
慢启动为发送方的TCP增加了另一个窗口：拥塞窗口 (congestion window)，记为cwnd。当与另一个网络的主机建立TCP连接时，拥塞窗口被初始化为1个报文段（即另一端通告的报文段大小）。每收到一个ACK，拥塞窗口就增加一个报文段（ cwnd以字节为单位，但是慢启动以报文段大小为单位进行增加）。发送方取拥塞窗口与通告窗口中的最小值作为发送上限。拥塞窗口是发送方使用的流量控制，而通告窗口则是接收方使用的流量控制。
发送方开始时发送一个报文段，然后等待ACK。当收到该ACK时，拥塞窗口从1增加为2，即可以发送两个报文段。当收到这两个报文段的ACK时，拥塞窗口就增加为4。这是一种指数增加的关系。
慢启动阶段思路是不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小，在没有出现丢包时每收到一个 ACK 就将拥塞窗口大小加一（单位是 MSS，最大单个报文段长度），每轮次发送窗口增加一倍，呈指数增长，若出现丢包，则将拥塞窗口减半，进入拥塞避免阶段；
2.拥塞避免
拥塞避免算法和慢启动算法需要对每个连接维持两个变量：一个拥塞窗口cwnd和一个慢启动门限ssthresh。这样得到的算法的工作过程如下：
1)对一个给定的连接，初始化cwnd为1个报文段，ssthresh为65535个字节。
2)TCP输出例程的输出不能超过cwnd和接收方通告窗口的大小。拥塞避免是发送方使用的流量控制，而通告窗口则是接收方进行的流量控制。前者是发送方感受到的网络拥塞的估计，而后者则与接收方在该连接上的可用缓存大小有关。
3)当超时或收到重复确认时，拥塞发生，ssthresh被设置为当前窗口大小的一半（cwnd和接收方通告窗口大小的最小值，但最少为2个报文段）。此外，如果是超时引起了拥塞，则cwnd被设置为1个报文段（这就是慢启动）。
4)当新的数据被对方确认时，就增加cwnd，但增加的方法依赖于我们是否正在进行慢启动或拥塞避免。如果cwnd小于或等于ssthresh，则正在进行慢启动，否则正在进行拥塞避免。慢启动一直持续到我们回到当拥塞发生时所处位置的半时候才停止（cwnd增加到ssthresh的大小），然后转为执行拥塞避免，从该时刻起，cwnd以线性方式增加，。
慢启动算法初始设置cwnd为1个报文段，此后每收到一个确认就加1。这会使窗口按指数方式增长：发送1个报文段，然后是2个，接着是4个……。 拥塞避免算法要求每次收到一个确认时将cwnd增加1/cwnd。与慢启动的指数增加比起来，这是一种加性增长(additive increase)。我们希望在一个往返时间内最多为cwnd增加1个报文段（不管在这个RTT中收到了多少个ACK），然而慢启动将根据这个往返时间中所收到的确认的个数增加cwnd
3.快速重传
我们认识到在收到一个失序的报文段时，TCP立即需要产生一个ACK（一个重复的ACK）。这个重复的ACK不应该被迟延。该重复的ACK的目的在于让对方知道收到一个失序的报文段，并告诉对方自己希望收到的序号。
当收到对一个报文的三个重复的 ACK 时，认为这个报文的下一个报文丢失了，进入快重传阶段，重传自那个序号起的一个报文段，要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方，可提高网络吞吐量约20%）而不要等到自己发送数据时捎带确认
4.快速恢复
快重传完成后进入快恢复阶段，将慢启动阈值ssthresh修改为当前拥塞窗口值的一半。当下一个确认新数据的ACK到达时，设置cwnd为ssthresh（在第1步中设置的值）。这个ACK应该是在进行重传后的一个往返时间内对步骤1中重传的确认。另外，这个ACK也应该是对丢失的分组和收到的第 1个重复的ACK之间的所有中间报文段的确认。进入拥塞避免阶段，重复上述过程。
BBR 是谷歌在 2016 年提出的一种新的拥塞控制算法，已经在 Youtube 服务器和谷歌跨数据中心广域网上部署，据 Youtube 官方数据称，部署 BBR 后，在全球范围内访问 Youtube 的延迟降低了 53%，在时延较高的发展中国家，延迟降低了 80%。
BBR 算法不将出现丢包或时延增加作为拥塞的信号，而是认为当网络上的数据包总量大于瓶颈链路带宽和时延的乘积时才出现了拥塞，所以 BBR 也称为基于拥塞的拥塞控制算法（Congestion-Based Congestion Control），其适用网络为高带宽、高时延、有一定丢包率的长肥网络，可以有效降低传输时延，并保证较高的吞吐量，与其他两个常见算法发包速率对比如下：
BBR 算法周期性地探测网络的容量，交替测量一段时间内的带宽极大值和时延极小值，将其乘积作为作为拥塞窗口大小，使得拥塞窗口始的值始终与网络的容量保持一致。
所以 BBR 算法解决了两个比较主要的问题：
在有一定丢包率的网络链路上充分利用带宽。
适合高延迟、高带宽的网络链路。
降低网络链路上的 buffer 占用率，从而降低延迟。
适合慢速接入网络的用户。
对每个连接，TCP管理4个不同的定时器。
-
重传定时器使用于当希望收到另一端的确认。TCP通过在发送时设置一个定时器来解决这种问题。如果当定时器溢出时还没有收到确认，它就重传该数据。连续重传之间不同的时间差，每次重传时增加1倍并直至64秒。这个倍乘关系被称为指数退避 (exponential backoff)。
-
坚持(persist)定时器使窗口大小信息保持不断流动，即使另一端关闭了其接收窗口（窗口大小为0）。
如果一个确认丢失了，则双方就有可能因为等待对方而使连接终止：接收方等待接收数据（因为它已经向发送方通告了一个非0的窗口），而发送方在等待允许它继续发送数据的窗口更新。为防止这种死锁情况的发生，发送方使用一个坚持定时器 (persist timer)来周期性地向接收方查询，以便发现窗口是否已增大。这些从发送方发出的报文段称为窗口探查 (window probe)。
当通告窗口为 0，客户停止发送任何其他的数据，设置其坚持定时器。如果在该定时器时间到时客户还没有接收到一个窗口更新，它就探查这个空的窗口以决定窗口更新是否丢失。
计算坚持定时器时使用了普通的TCP指数退避
-
保活(keep alive)定时器可检测到一个空闲连接的另一端何时崩溃或重启。
-
2MSL定时器测量一个连接处于TIME_WAIT状态的时间。
不同的域名通过A记录或者CNAME方式可以连接都同一个IP下，同一个IP也可以设置多个不同站点，那我访问不同的域名都转发到同一IP，怎么区分这些不同的站点呢，就是用的Host字段，如果服务器后台解析出Host但是服务器上找不到相应的站点，那么这个连接很可能会被丢弃，从而报错。
在介绍HttpOnly之前，我想跟大家聊聊Cookie及XSS。
随着B/S的普及，我们平时上网都是依赖于http协议完成，而Http是无状态的，即同一个会话的连续两个请求互相不了解，他们由最新实例化的环境进行解析，除了应用本身可能已经存储在全局对象中的所有信息外，该环境不保存与会话有关的任何信息，http是不会为了下一次连接而维护这次连接所传输的信息的。所以为了在每次会话之间传递信息，就需要用到cookie和session，无论是什么，都是为了让服务器端获得一个token来检查合法性，很多时候都是在cookie中存储一个sessionID，服务器来识别该用户，那么安全隐患也就引申而出了，只要获得这个cookie，就可以取得别人的身份，特别是管理员等高级权限帐号时，危害就大了，而XSS就是在别人的应用程序中恶意执行一段JS以窃取用户的cookie。
那么如何获得Cookie劫持呢?在浏览器中的document对象中，就储存了Cookie的信息，而利用js可以把这里面的Cookie给取出来，只要得到这个Cookie就可以拥有别人的身份了
Cookie都是通过document对象获取的，我们如果能让cookie在浏览器中不可见就可以了，那HttpOnly就是在设置cookie时接受这样一个参数，一旦被设置，在浏览器的document对象中就看不到cookie了。而浏览器在浏览网页的时候不受任何影响，因为Cookie会被放在浏览器头中发送出去(包括Ajax的时候)，应用程序也一般不会在JS里操作这些敏感Cookie的，对于一些敏感的Cookie我们采用HttpOnly，对于一些需要在应用程序中用JS操作的cookie我们就不予设置。
那问题就来了，大家想想，HttpOnly 主要是为了限制web页面程序的browser端script程序读取cookie， 实际是浏览器通过协议实现限制的，黑客可不会那么傻，肯定不会用HTTP协议来读取cookie，肯定是在socket层面写抓包程序，相当于写一个低于IE6版本的应用程序。
所以，HttpOnly并不是万能的。
幂等idempotent :如果一个方法重复执行多次，产生的效果是一样的，那就是幂等的。幂等的意思是如果相同的操作再执行第二遍第三遍，结果还是一样。
HTTP协议中请求的8中方法
- OPTIONS获取服务器支持的HTTP请求方法；如果请求成功，会有一个Allow的头包含类似“GET,POST”这样的信息
- HEAD跟get很像，但是不返回响应体信息，用于检查对象是否存在，并获取包含在响应消息头中的信息。
- GET向特定的资源发出请求，得到资源。
- POST向指定资源提交数据进行处理的请求，用于添加新的内容。
- PUT向指定资源位置上传其最新的内容，用于修改某个内容。
- DELETE请求服务器删除请求的URI所标识的资源，用于删除。
- TRACE回馈服务器收到的请求，用于远程诊断服务器。
- CONNECT用于代理进行传输，如使用ssl
POST：用来创建一个子资源
如 /api/users，会在users下面创建一个user，如users/1；POST方法不是幂等的，多次执行，将导致多条相同的条目被创建。（比如在提交表单时刷新，会POST多个相同的表单给服务器）。重点：POST不是幂等的。
PUT：比较正确的定义是Create or Update
例如 PUT /items/1 的意思是替换 /items/1 ，存在则替换，不存在则创建。
所以，PUT方法一般会用来更新一个已知资源。
PATCH：是对PUT方法的补充，用来对已知资源进行局部更新，PATCH是幂等的。
假设我们有一个UserInfo，里面有userId， userName， userGender等10个字段。可你的编辑功能因为需求，在某个特别的页面里只能修改userName，这时候的更新怎么做？
人们通常(为徒省事)把一个包含了修改后userName的完整userInfo对象传给后端，做完整更新。但仔细想想，这种做法感觉有点二，而且真心浪费带宽(纯技术上讲，你不关心带宽那是你土豪)。
于是patch诞生，只传一个userName到指定资源去，表示该请求是一个局部更新，后端仅更新接收到的字段。
而put虽然也是更新资源，但要求前端提供的一定是一个完整的资源对象，理论上说，如果你用了put，但却没有提供完整的UserInfo，那么缺了的那些字段应该被清空
POST /api/articles
PUT /gists/:id/stars
如果产生两个资源，就说明这个服务不是idempotent（幂等的），因为多次使用产生了副作用；如果后一个请求把第一个请求覆盖掉了，那这个服务就是idempotent的。
前一种情况，应该使用POST方法；
后一种情况，应该使用PUT方法。