weixin_61501031的博客

以 CSRF 攻击乃伪请求自服务器来，故禁跨域访问，于服务器端加验，滤非本服务器所发之请求，此可稍避 CSRF 攻击。然其亦有弊，若自搜索引擎搜索结果跳转而来，请求亦或被视为跨域请求。当用户以正途访服务器时，服务器生随机字符串，存于 session 中，以为令牌（token）返予客户端，隐于客户端内。客户端每发请求，皆携此 token，服务器据之判请求之合法与否。CSRF 攻击，乃请求伪造之术，因服务器难辨用户之属，遂盗用户信息以攻之。故御此攻击，当自服务器端入手，增其辨识之能，设善御之制。

TCP 之三次握手与四次挥手，乃网络通信建连与断连之要则，今详述之。

此时，发送主机会以目的主机之 IP 地址为内容，行广播 ARP 请求，冀得目的主机之 MAC 地址。然唯目的主机接此 ARP 请求后，会将自身 MAC 地址与 IP 地址装入 ARP 应答，回复于发送主机。发送主机收此 ARP 应答，从中提目的主机之 MAC 地址，于其 ARP 表中建立目的主机对应表项（即 IP 地址至 MAC 地址之映射）。此后，发送主机便可向目的主机发送数据，将待发数据封装成帧，借二层设备（如交换机）转发至本网段内之目的主机，如此，则通信乃成。其连接处，即为网络关卡，是谓网关。

浏览器先验签名真伪，若签名无误，再核证书网址与当前网址是否相同，若异，则示警。服务器以自身密钥解之，得此随机值，再将欲传信息与私钥，依算法相混加密，复传客户端。客户端遂以先前所生私钥，解此密文，至此，信息传递，终得畅达。凡行 HTTPS 协议之服务器，必有数字证书一套，内含公钥、密钥，此乃通信之根本，犹门户之锁钥。HTTPS 加密认证之法，以证书为信，以算法为术，层层设防，如铜墙铁壁，护信息传输于网络之间，使数据往来，无泄露之险，得安全之实。其加密认证之程，环环相扣，犹如精工织锦，严密无隙，今述其详。

然其亦有妙处，不占服务器之资，如轻舟泛水，省却负担。且单个 Cookie 所容数据有限，不过 4K ，犹小匣藏物，量少难丰。网络会话之术，Cookie 与 Session 皆为常用之道，犹双楫行舟，各有所长。以购物车为例，当用户点击下单，服务端欲辨其详，知车中物几何，常借二者以识用户、循其迹。然二者之性，实有云泥之别，今详述之。Session 者，数据栖于服务器，似珍宝藏于府库，严密有加，安全可恃，故涉及私密，多用此道。犹如巨舰行江，需力甚多。用者当审时度势，依场景而择，方能使网络会话顺畅，信息往来无虞。

反观 POST 请求，无参数长度之缚，如长河行舟，可载万斛。于浏览器回退时，若用 POST ，则如旧令再行，请求复提，或生重复之患。GET 之请求，参数附于 URL ，然其长有限制，如短绳系物，难载千钧。且参数显露于 URL ，犹如敞门示宝，人皆可见，故非宜传敏感信息，易招窥探之险。其参数唯可经 URL 编码，且易为浏览器缓存，所生 URL 可存为书签，于浏览器回退时，无复提交之忧，恰似旧路重行，波澜不惊。网络通信中，GET 与 POST 二请求，虽皆为传信之法，然其性殊异，犹云泥之别，今析而论之。

客户端发送附带条件的请求时，服务器端允许请求访问资源，但因发生请求未满足条件的情况后，直接返回了 304。: 跳转，代表永久性重定向（请求的资源已被分配了新的URI，以后已使用资源，现在设置了URI）。: 临时性重定向（请求的资源已经分配了新的URI，希望用户本次能够使用新的URI来进行访问）。: 由于请求对应的资源存在的另一个URI（因使用get方法，定向获取请求的资源）。: 部分的内容（如：客户端进行了范围请求，但是服务器成功执行了这部分的干请求）。: 发送的请求需要有通过HTTP认证的认证信息。

行多路复用之术，于一 TCP 内，众请求并行不悖，往昔雪碧图、多域名散列般优诸化，至此皆成冗余。更有服务端推送之能，主动献资源于客户端，不待求索，如商贾迎宾，先呈珍宝。默认启长连接，使 HTTP 请求得复用 TCP ，然同一时刻，仅容一请求行于 TCP ，如单骑过隘，次第而行。其缓存之法，强缓存 expired 、协商缓存 last - modified 与 if - modified - since ，皆有缺隙，犹璞玉未琢，有待完善。1.0 立其基，1.1 补其漏，2.0 破其囿，使网络传输，日臻佳境。

GET 者，访 URI （统一资源标识符）所识资源，可经 URL 传参于服务器，常取信息。POST 者，传信息至服务器，类 GET，然可传数据量更大且更安全，多用于表单提交。OPTIONS 者，查相应 URI 支持之 HTTP 方法，明交互规则。HTTP 诸方法，各司其职，共促网络通信有序，使信息、资源操控自如。DELETE 者，删对应 URI 处之文件，与 PUT 相反。HEAD 者，得报文首部，不返主体，验 URI 有效与否。PUT 者，传文件，将文件内容存于对应 URI 处。

依请求后缀差异，如静态 *.html、动态 *.shtml，可定规则：唯自站 Referer 者，方许动态请求通行，若越规而来，则斥为恶意，此乃以规立界，御不速之客。不许，则禁之，此乃开闭门户之辨也。览器向 web 服务器发请求时，多携此头，以告服务器该网页之来源，助其处理事务，其用有三。若服务器欲护资源，仅许指定域名访问，便可依 Referer 核验，非白名单内域名，则拒之门外，此乃以源溯迹，守资源之门。Referer 头虽微，然于网络防护，如锁钥之于门户，用之得当，则可护资源、御风险，维系网络秩序。

二者相较，差异显焉。HTTPS 需于 CA 求证书，然免费者鲜，多费资财，若珍器重宝，需以金帛易之。其连接之道亦殊，HTTP 用 80 端口，简而无态，往来无记；HTTPS 以 443 端口，融 SSL 与 HTTP，加密传输，认证身份，固若金汤，且严守门户，不使旁入。于 HTTP 之下，嵌入 SSL 层，其安之所系，尽在 SSL。HTTP 者，广行于网络，乃客户端与服务器应答之准则，基于 TCP 而设，专司自 WWW 服务器传超文本至本地览器之职。其行也简，使览器高效，减网络传输之赘，轻快自如。

浏览器再发请，索 HTML 内藏之诸资，如图、音、视、CSS、JS 等。浏览器遣 HTTP 之请求于 web 服务器。服务器复 HTTP 之答。浏览器展 HTML 之容。服务器返永久重定向之应。浏览器觅域名之 IP。

端到端与点到点之通信，于网络之境，各有其位，其别若云泥，今详述之，以明其理。

服务器欲断客户端之连接是否已断，其法大抵有二：曰 keepalive，曰 heart - beat。二者虽皆为探虚实之策，然其道殊异，今试析之。

欲使 TCP 加速大文件之传输，需善用诸策，犹如驭马行远路，唯调御得法，方得疾行。今详述其术，以窥网络传输之妙。

TCP 协议之妙，在于其延迟 ACK 与累计应答之制，此二者相辅相成，恰似双璧，护网络数据传输之稳，今且述之。

HTTP 之 Keep - Alive 与 TCP 之 KEEPALIVE，虽名相近，然其义大异，今析而论之。

此制犹如信使之牌符，每发数据，皆附特定序号（seq），待对方收讫，必回确认（ack）之讯。如此，可保数据无失，必达彼端，恰似驿道传书，以牌符验信之真伪、定信之至否。且依时势，或增或减重发之频，务使数据得达。若逾时未得确认，则自缓冲区取数据重发，以防信息遗失，犹农夫蓄水，旱时可灌田亩。至于连接之建断、传输之可靠，皆非其所虑，悉委于上层应用层之程序处置，自身唯守传输层协议之本分耳。UDP 虽本性疏简，然借应用层巧设诸制，亦能趋近可靠，犹璞玉经琢，终成器用，于网络传输中，别开生面，济 TCP 所不及之处。

TCP 与 UDP，皆为网络协议中传输层之要角，其性其用，各有千秋，今试析之。

彼时，服务端需经多次读取，方得收全 D1、D2，其间拆包频发，恰似长河行舟，屡遭险滩，风波不断 ，数据传输之序，亦因此而乱。其三，服务端两度读取，初得完整之 D1，及 D2 之一部，再得 D2 之残剩，此乃 TCP 拆包，若断玉碎璧，本为一体，却遭分割；其四，服务端两度读取，先取 D1 之一部，曰 D1_1，后取 D1 之其余，及完整之 D2，亦属拆包之例，犹书卷散佚，页码错乱。其一，服务端两度读取，各得一独立之包，D1、D2 分明，无粘包、拆包之患，恰似两舟顺流而下，各不相扰；

SYN Flood 者，当今盛行之 DoS（拒绝服务攻击）与 DDoS（分布式拒绝服务攻击）手段也。此攻术，乃借 TCP 协议之隙，发海量伪造之 TCP 连接请求，致使被攻者资源竭尽，或 CPU 不堪重负，或内存匮乏难支，犹如洪水漫堤，冲垮网络之根基。欲防此类攻击，或遇攻而求应，有三策可施：其一，购互联网服务提供商（ISP）之服务。诸多 ISP 皆供 DDoS 缓解之务。然企业网络遭攻时，必报于 ISP，始得解困。此策号曰 “清洁管道” ，于 ISP 收费之模式下，颇为流行。然缓解之效，常迟于事发，自报事至

设若客户端不待 2MSL，发 ACK 后即释连接，一旦 ACK 失，服务器便困于不闭之境，如舟失锚，飘摇而不得安泊。此 2MSL 之期，恰似守望之岗，静候往来讯息，待诸事妥帖，方许撤防。如此，新连接方无旧报文段混杂之患，免致新旧错乱，如陈酿入新樽，污其清冽。此乃以时间为帚，扫尽旧迹，使新起之连接，纯净无扰，畅行无阻。其理如江河行舟，久滞则腐，必令其流转，免致壅塞。2MSL 之设，非徒延时，实乃匠心独运，以时间为经纬，织就网络通信之密网，防疏漏于未然，保连接始终有序，使信息往来，如江河归海，终得圆满。

如守关之士，静待余波，以防意外之变，必待诸事宁定，方撤关隘。此态也，非冗余之举，实乃周全之策，护网络通信终始无虞，使连接关闭之际，亦得圆满无缺。依 MSL 值，有处置之则：当 TCP 行主动关闭，且发最后之 ACK 后，此连接须于 TIME_WAIT 状态驻留二倍 MSL 之时长。若其失也，彼端将因超时重发最后之 FIN，而 TCP 可借此时限，复发 ACK 以应，保连接关闭之序。TCP 之 TIME_WAIT 状态，又称 2MSL 等待之态，其设之妙，关乎网络通信之稳，今释其详。

Server 端依 TCP 超时重传机制，先候三秒，未得则再候六秒，又未得则候十二秒，而后重发 SYN + ACK 包，盼 Client 能重发 ACK 包。若重发达指定次数，仍未收 client 之 ACK 应答，经时既久，Server 自会关闭此连接。此时，请求方待至超时，便行重传之举，冀得回应，以成连接之始。三次握手，如连环之扣，任一扣失，皆影响连接之成。失则补救，或重传，或待时，各依其规，以图网络连接顺畅，信息往来无阻。TCP 三次握手，关乎连接之立，若每次握手信息对方未收，其情各殊，今分而述之。

若窗口过小，当传输大量数据之时，便需频繁确认。每发一数据，皆候确认，方能续发下一个。如此往复，如人行长途，步步需停待许可，行程必缓。此将致延迟大增，恰似江河行舟，若每过一湾，皆久泊待令，航运之速必大受影响。数据传输亦复如是，传输效率因之锐减，网络之畅达受阻，实不利于大数据量之高效传输。今论滑动窗口过小之况。设窗口之大小为一，意即每次仅能发一数据。且发送方必待接收方确认此数据后，方得发下一个数据。

若 TCP 累积确认未能返新 ACK，或 ACK 中所涵选择确认信息（SACK）示报文失序，快速重传机制即判有包丢失，需为重传之举。二者相辅相成，滑动窗口调发送之速，重传机制补传输之失。宛如行车之道，滑动窗口如限速之规，保车辆有序前行；重传机制似救援之措，遇障则补，共保网络数据传输之路畅达无虞，使信息往来顺遂，不失其序。盖若发送方发速过快，接收方或因难容海量数据而致壅塞，此机制恰如筑堤防洪，使水流有序。TCP 之滑动窗口与重传机制，乃网络传输中至关紧要者，其理精妙，今详明之。

TCP 之可靠性，赖诸般精妙之法以成，其要者有检验和、序列号 / 确认应答、超时重传、最大消息长度、滑动窗口控制及拥塞控制数端。

此过程也，犹人行路寄信，每发一信，便心记时日，盼得回音。若逾期未闻回音，便疑信已失，遂重写重寄。TCP 借超时重传之法，以保数据无失，恰似使者护持信笺，虽途有坎坷，亦必使信息达于彼端，成就网络通信之稳靠。TCP 欲成其可靠之能，处理数据超时与重传，乃至要之机制也。依 TCP 协议之规，发送端每发一报文段，即启一定时器，旋而静候确认之息。接收端若得新数据，必回返确认之讯。设若定时器时限已至，而数据未得确认，TCP 则判此报文段中数据或已遗失，或遭损坏。此时，发送端当对该报文段内数据，重加整理，再度传送。

故而，基于模型之拥塞控制算法，能有更高之吞吐量，且延迟更低，可用 BBR 以替他流行之拥塞算法，如 CUBIC 者。若 Tahoe 算法下，收三次重复确认，则入快重传，即速重发失包，且置慢启动阈值为当前拥塞窗口之半，设拥塞窗口为 1MSS，遂入慢启动之态。而 Reno 算法，收三次重复确认时，虽亦入快重传，却不进慢启动，直将拥塞窗口减半，转而进入拥塞控制之阶段，此谓 “快恢复”。TCP 之拥塞控制算法，各有其长，随网络之变而演进，皆为使网络传输高效、稳定，宛如舟行江河，依水势而调帆，以达顺畅之境。

若校验无误，则将数据交予上层协议，继而发一累计应答包与发送方，以示该数据已收。每值主机发数据，TCP 为各数据包分予序列号，且设特定之时限，待接收主机确认此序列号。其三，若定时器超时前，收对方发来应答信息（或为对本包之应，或为对本包后续包之应），则释此数据包所占缓冲区。由此观之，TCP 借序列号、定时器、缓冲区及应答等手段，环环相扣，确保数据有序且可靠地传输，宛如精巧之器，运转自如，成就网络数据往来之顺畅。其四，若未得应答，则重发该数据包，直至收得应答，或重发次数超所定最大次数方止。

若遇段之丢失，TCP 视之为网络壅塞，遂施术以缓网络之挤。一旦逢丢失之事，或至阈值，则 TCP 入线性增长阶段。于斯时也，每经一 RTT，窗仅增一段矣。慢启动者，亦号指数增长期。每于 TCP 接收之窗得确认时，其窗则长，所增长之量，即已确认段之数也。此状恒持，直至有段未得收，或窗之大小至预立之阈。TCP 者，网络传输之要法也。其有慢启动之制，乃阻塞控御之策焉。

于状转图中，尚有一情，若客户端发 SYN 之同时，亦收服务器端之 SYN 求，即二者同发连求，则客户端自 SYN_SENT 态转至 SYN_RCVD 态。客户端启连，调用 connect，发 SYN 至服务器端，旋即入 SYN_SENT 之态，待服务器端之确认（即三次握手中之第二报文）。CLOSING 者，若两边同发闭连之求（即主动方发 FIN，候被动方返 ACK，同时被动方亦发 FIN，主动方收此 FIN 后，发 ACK 予被动方），主动方自 FIN_WAIT_1 态入此态，候被动方返 ACK。

TCP 务使数据依序而发，依序而至，且设超时重传之制，以保可靠。然 UDP 则不然，既不确保数据按序送达，甚至或有不达者，仅尽力而付。其意在于，未传实际数据之先，TCP 之客户端与服务器端，必经三次握手，方得建连。UDP 则面向报文之服务，各报文独立，自成一体。而 UDP 之能，更胜一筹，可支一对一、多对多、一对多之通信，其用更广。由此观之，TCP 与 UDP，各因其性，适用于不同之场景，各司其职，共襄网络传输之大业。TCP 与 UDP，乃网络传输之二大要则，其性与形，各有殊异，今详明之。

若仅行两次握手，唯发起连接之一方，其序列号起始值可得确认，而另一方所择序列号，则不得证。仅传两次信，仅一方能知自身起始之序得对方晓，而另一方起始序之晓于对方否，未可知也。故两次握手难成稳靠通信，三次握手方为确保持续、可靠数据传输之良策，使双方序列号起始值皆得确认，而后数据往来有序，无混淆错漏之虞。通信之双方，皆需持一序列号，以明所发数据包中，何者已为对方所收。三次握手之流程，乃双方互告序列号起始之值，并证对方已收此起始值之必要径也。今论 TCP 握手之事，或问：两次握手可行否？

至于网络通信，无论局域之网，抑或广域之网，计算机间数据往来，终归于数据包之传递。而此过程中，数据包于节点间之移转，端赖 ARP（即地址解析协议）之力。ARP 者，能将 IP 地址巧妙映射为 MAC 地址，恰似桥梁，沟通逻辑与物理地址之两岸，令数据传输得以精准无误地完成。设若构建高效路由之策，仅着眼于设备制造方，而罔顾网络拓扑之实，此策必难施行。盖网络拓扑千变万化，依拓扑分配 IP 地址，方能契合网络运行之需，使数据流转畅达。其于设备制造之时，已铭刻于硬件，仿若人之指纹，独一无二，标识设备于网络之具体所在。

com 域服务器接此请求后，亦不直返域名与 IP 之对应，而告本地 DNS 服务器，该域名解析服务器之地址。至于 DNS 劫持，乃以劫持 DNS 服务器之手段，得某域名解析记录之控制权，进而改其解析结果。终，本地 DNS 服务器向域名之解析服务器发请求，此时可得域名与 IP 地址之对应关系。本地 DNS 服务器既得此对应，一则返 IP 地址于用户电脑，二则存此对应于缓存，以备它用户再查时，可直返结果，速网络访问之效。”，此时所用之电脑，即发 DNS 请求，达于本地 DNS 服务器。

无论本地 DNS 服务器采用转发之法，还是根提示之策，最终皆将结果返回给本地 DNS 服务器，再由此 DNS 服务器返回给客户机。其三，若 hosts 与本地 DNS 解析器缓存皆无相应之网址映射，便先寻 TCP/IP 参数所设之首选 DNS 服务器，即本地 DNS 服务器。其四，若所查域名不由本地 DNS 服务器区域解析，然此服务器已缓存此网址映射关系，则调用此 IP 地址映射，完成域名解析，唯此解析不具权威性。其二，若 hosts 中无此域名之映射，则查本地 DNS 解析器之缓存，看有无此网址映射。

路由协议者，乃路由器间共享路由信息之机制也，使路由器得以互易并维护各自路由之表。EIGRP 乃增强之 IGRP 协议，为动态内部网关路由协议，仍用矢量－距离算法，然其实现较 IGRP 多有改进，收敛特性与操作效率大增。路由之算法，有必行之步骤焉。其三，据所得信息，算出至各目的网络之最优路径，进而成路由选择之表；其四，遇网络拓扑之变，能及时应之，调路由、创新表，且以拓扑之变，为路由信息，宣告于它路由器。EIGRP 非周期性更新，路径度量标准变时，仅发局部更新信息，且此信息传输自动受限，仅需者得之。

至于动态路由，则异于此。其由路由之协议自行构建，诸协议相互交流其所知之路由信息，以实时更新路由之表。此可自动洞察网络之拓扑，而适时更易路由之径。然其短亦明，盖路由广播更新之信息，常占甚多网络之带宽，致网络或有壅滞之虞。二者各有优劣，当因时制宜，择善而用之，方可得网络之畅达。路由之法，有静动之分。静态路由者，乃系于系统之管理员，依其筹谋而设路由之表，以定其径。此道适用于网关寡少之域，且网络之拓扑结构恒常不变者。然其弊亦显，盖因其不能随网络之变而自动更易，每遇网络之变，必赖管理员亲为改易路由之表，方得适配。