ybigbear1的博客

假设B是较A低的模块，但B需要使用到A的功能，这个时候，B不应当直接使用A中的具体类：而应当由B定义一抽象接口，并由A来实现这个抽象接口，B只使用这个抽象接口：这样就达到了依赖倒置的目的，B也解除了对A的依赖，反过来是A依赖于B定义的抽象接口。比如：一个网络模块，原来只服务端功能，而现在要加入客户端功能，那么应当在不用修改服务端功能代码的前提下，就能够增加客户端功能的实现代码，这要求在设计之初，就应当将服务端和客户端分开，公共部分抽象出来。局部变量：随着方法的调用而存在，随着方法的调用完毕而消失。

继承(Inherit)：继承实际上也是为了提高代码的复用性和可扩展性，在定义不同类的时候存在一些相同属性，为了方便使用可以将这些共同属性抽象成一个父类，在定义其他子类时可以继承自该父类，减少代码的重复定义，子类可以使用父类中非私有的成员。方法重载（overload）实现的是编译时的多态性（也称为前绑定），而方法重写（override）实现的是运行时的多态性（也称为后绑定）。方法的重载和重写都是实现多态的方式，区别在于前者实现的是编译时的多态性，而后者实现的是运行时的多态性。只有private构造方法。

接着悄悄创建目标站点的隐藏框架页，中间人返回特定的页面内容，其中的脚本即可修改目标站点 Cookie 了。HTTPS是在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版。另外，当浏览器访问HTTPS通信有效的Web网站时，浏览器的地址栏内会出现一个带锁的标记。不过 XSS 也不是也想有就能有的，但在特殊的条件下，任何站点都可以有 XSS —— 那就是流量被劫持的时候。通过代理，我们模拟流量被劫持的场景。当然，这种所谓的『拒绝服务』，只是本地自欺欺人而已，对真实服务器并没什么影响。

有没有想过，如果网站的 Cookie 特别多特别大，会发生什么情况？什么，网站居然报错了？众所周知，Cookie 是塞在请求头里的。如果 Cookie 太多，显然整个 HTTP 头也会被撑大。然而现实中，几乎所有的服务器都会对请求头长度做限制，避免畸形封包消耗服务器资源。那么有趣的事就来了 —— Cookie 是可以长期储存的，所以只要不过期，对应的站点就一直无法访问！为什么会这样！因为博客园是支持自定义装扮的，用户可以嵌入自己的脚本。

其实我原本以为我很懂 Cookie 跟 Session，但越研究越发现好像不是这么一回事，只是我自我感觉良好而已。但把该看的数据都看完一遍之后，再让自己沉淀个几天，大致上就能完全理解整个脉络的发展。Session 是什么？就是一种让 Request 变成 Stateful 的机制。以小明的例子来说，Session 就是一种让客人之间能互相关联起来的机制。在故事里面我们用了纸条跟手机里的信息来比喻，有多种方式可以达成 Session。

跟之前一样，他们都是透过一张纸条或者是手机里的信息来沟通，但唯一的差别是客人跟小明之间只透过 A59Uhe7I94J330mN 这个存在手机里的 ID 来验证身份，其他相关资讯都写在小明的笔记本里面。但有一个小缺点，那就是当小明想存的信息愈来愈多之后，这一串字也会愈来愈长，就会在客人的手机里面占更大的容量。这种验证的方法就像是我曾经去过的网咖。我只要去打咖的时候出示这张会员卡，店员就知道我曾经消费过多少钱，也知道我喜欢点的餐点，所有的信息都是存在他们的系统里面，而我的身份就是透过这张会员卡来表示。

Session 是什么？重点是手机里的信息取代了以前的纸条，客人不用刻意再带一个没有用的纸条了，只需要把本来就会随身携带的手机拿出来就好，跟以前相比方便许多。让我们先从比喻回到网络世界里，HTTP 是无状态的，所以每一个 Request 都是不相关的，就像是对小明来说每一位客人都是新的客人一样，他根本不知道谁是谁。前面已经有提过了，尽管小明靠着这个纸条的机制留住了一些常客，但是新客人呢？但有了纸条以后，两个在小明眼中完全不同的客人被关联了起来，小明就可以知道：「原来这个新的客人是以前那个来买木材的客人！

小明身为杂货店的店长兼唯一的店员，所有大小事都是他一个人在处理。传统杂货店跟便利商店最大的差别在哪里？在于人情味。就像是你去菜市场买菜的时候会被说帅哥或美女，或者是去买早餐的时候老板会问你：「一样？」，你只要点个头就行了。这些人与人之间的情感是无论信息怎么发展都无法取代的。可是小明没有办法，因为他根本记不起来是同一个人。每一个来店里的人对小明来说都是一个独立的个体，是完全不相干的。你可能会疑惑说：「就算认不出脸，认声音、衣服、气味也都可以吧？」，看来你是太低估小明了。

小明平时人缘还算不错，在倒垃圾时会与旁边的婆婆妈妈闲聊，说着那个谁谁谁的儿子考上了台大，谁谁谁的女儿最近交了个男友，成为左邻右舍八卦网络的一部分。于是，小明就用了退休金在家里附近的巷口开了间杂货店，并且取名为：「小明の杂货店」，是个毫无创意的名称，但把自己的名字放在招牌上一直是他的梦想。但开幕毕竟是开幕，通常都是一家商店这辈子的巅峰，除非有跳楼大拍卖（假的那种不算，例如说每天都在大拍卖的）或是周年庆，不然都很难超越了。要向没有技术背景的人讲这种概念性的东西，用一堆专有名词绝对是最差劲的做法。

肯定不能只开一个 TCP 连接顺序下载，那样用户肯定等的很难受，但是如果每个图片都开一个 TCP 连接发 HTTP 请求，那电脑或者服务器都可能受不了，要是有 1000 张图片的话总不能开 1000 个TCP 连接吧，你的电脑同意 NAT 也不一定会同意。那浏览器就会在一个 HOST 上建立多个 TCP 连接，连接数量的最大限制取决于浏览器设置，这些连接会在空闲的时候被浏览器用来发送新的请求，如果所有的连接都正在发送请求呢？一个支持持久连接的客户端可以在一个连接中发送多个请求（不需要等待任意请求的响应）。

持久连接：既然维持 TCP 连接好处这么多，HTTP/1.1 就把 Connection 头写进标准，并且默认开启持久连接，除非请求中写明 Connection: close，那么浏览器和服务器之间是会维持一段时间的 TCP 连接，不会一个请求结束就断掉。在传统的HTTP/1.0协议中，每次HTTP请求都需要单独建立一个TCP连接，请求完成后立即关闭连接，这样导致了在多次请求时产生了较大的开销。意思是说，完成这个 HTTP 请求之后，不要断开 HTTP 请求使用的 TCP 连接。

若不确定这种方式是否关闭了原本正常的客户端，则在ShutDown的时候一定要选择send,表示关闭发送通道，服务器还可以接收一下，万一客户端正在发送比较重要的数据呢，是不？这时候就有个问题，若利用轮询还未检测出上条旧连接已经超时（这很正常，timer总有个间隔吧），而在这时，客户端又重复的上演情况3，那么服务端将会出现大量的假的ESTABLISHED连接和CLOSE_WAIT连接。但是能肯定的是，这个问题的产生绝对是设备在不停的重启，而服务器这边又是简单的轮询，并不能及时处理，暂时还未能解决。

TCP报头内的确认编号栏内包含的确认编号(w+1，Figure-1)为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。PSH为1的情况，一般只出现在 DATA内容不为0的包中，也就是说PSH为1表示的是有真正的TCP数据包内容被传递。其中，ACK是可能与SYN，FIN等同时使用的，比如SYN和ACK可能同时为1，它表示的就是建立连接之后的响应，但SYN与FIN是不会同时为1的，因为前者表示的是建立连接，而后者表示的是断开连接。TCP的连接建立和连接关闭，都是通过请求－响应的模式完成的。

当Server端调用socket函数调用时，相当于Server端产生了一个处于Closed状态的监听套接字，Server端调用bind操作，将监听套接字与指定的地址和端口关联，然后又调用listen函数，系统会为其分配未完成队列和完成队列，此时的监听套接字可以接受Client的连接，监听套接字状态处于LISTEN状态。这是三次握手过程中的报文1。：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

这是一个看起来比较复杂的状态迁移图，因为它包含了两个部分—-服务器的状态迁移和客户端的状态迁移，如果从某一个角度出发来看这个图，就会清晰许多，这里面的服务器和客户端都不是绝对的，发送数据的就是客户端，接受数据的就是服务器。而结束连接则通常是客户端主动结束的，客户端结束应用程序以后，需要经历FIN_WAIT_1，FIN_WAIT_2等状态，这些状态的迁移就是前面提到的结束连接的四次握手。那么你就一定要对这张图的每一个状态，及转换的过程有深刻的认识，不能只停留在一知半解之中。客户端应用程序的状态迁移图。

看LISTENING状态最主要的是看本机开了哪些端口，这些端口都是哪个程序开的，关闭不必要的端口是保证安全的一个非常重要的方面，服务端口都对应一个服务（应用程序），停止该服务就关闭了该端口，例如要关闭21端口只要停止IIS服务中的FTP服务即可。TIME_WAIT等待状态，这个状态又叫做2MSL状态，说的是在TIME_WAIT2发送了最后一个ACK数据报以后，要进入TIME_WAIT状态，这个状态是防止最后一次握手的数据报没有传送到对方那里而准备的（注意这不是四次握手，这是第四次握手的保险状态）。

客户端发送了FIN，但是没有收到服务器的ACK，却收到了服务器的FIN，这种情况发生在服务器发送的ACK丢包的时候，因为网络传输有时会有意外。4、服务器收到客户端的报文后向客户端发送ACK和SYN报文，此时服务器的状态变为SYN_RCVD；5、然后，客户端收到ACK、SYN，就向服务器发送ACK，客户端状态变为ESTABLISHED；5、客户端收到服务器的FIN后，马上发送ACK给服务器，此时客户端进入TIME_WAIT状态；2、服务器收到FIN后向客户端发送ACK，服务器的状态围边CLOSE_WAIT；

2、由服务端回复客户端发送的TCP连接请求报文，其中包含seq序列号，是由回复端随机生成的，并且将SYN置为1，而且会产生ACK字段，ACK字段数值是在客户端发送过来的序列号seq的基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP建立请求已得到验证。2、服务端会回复客户端发送的TCP断开请求报文，其包含seq序列号，是由回复端随机生成的，而且会产生ACK字段，ACK字段数值是在客户端发过来的seq序列号基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP断开请求已经得到验证。

第一次握手：客户端发送网络包，服务端收到了。服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常？第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。因此，需要三次握手才能确认双方的接收与发送能力是否都正常。

然后客户端再回复一段报文给服务端，报文包含ACK标志位(ACK=1)、ack=301(服务端序列号+1)、seq=101(第一次握手时发送报文是占据一个序列号的，所以这次seq就从101开始，需要注意的是不携带数据的ACK报文是不占据序列号的，所以后面第一次正式发送数据时seq还是101)。第二次握手：服务端收到客户端发过来的报文后，发现SYN=1，知道这是一个连接请求，于是将客户端的起始序列号100存起来，并且随机生成一个服务端的起始序列号(比如是300)。这些参数可以放在TCP头部。

互联网使用的网络层协议是无连接的网际协议（Intert Prococol）和许多路由选择协议，因此互联网的网络层也叫做网际层或 IP 层。应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则。在互联网中应用层协议很多，如域名系统 DNS，支持万维网应用的 HTTP 协议，支持电子邮件的 SMTP 协议等等。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。用户数据协议-UDP：提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）。