最近开始刷leetcode，刷了一周时间，确实会上瘾，不过能巩固很多基础知识，包括算法和语言。我现在是架构与编码并行。今天遇到的是两个列表的合并，刚开始我自己写了一个笨方法来合并，虽然通过了测试，但是代码质量不高，于是研究了其他人写的代码。

//传入的两个链表本身是从小到大排序好
public ListNode MergeTwoLists(ListNode list1, ListNode list2)
{
    ListNode head = new ListNode(); //定义新的链表头
    ListNode current = head;//定义链表最新的next地址
    //遍历两个链表，任何一个完毕后就终止循环
    while (list1 != null && list2 != null)
    {
        if (list1.val < list2.val)
        {
            //如果list1的元素值小，则把当前list1赋予current.next，注意这里相当于head.next
            current.next = list1;
            list1 = list1.next;
        }
        else
        {
            current.next = list2;
            list2 = list2.next;
        }
        //将current变量指向current.next，相当于head.next,当进入下一次循环给current.next赋值的时候，相当于是给head.next.next赋值了，一直这么循环到最后
        current = current.next;
    }
    //head链表的next指向未循环完成的部分
    current.next = list1 == null ? list2 : list1;
    //返回合并后的链表
    return head.next;

}

我刚开始发懵了，居然没理解这部分代码，因为忽略了“每次循环之后current的引用指向已经发生变化”。

赋值和深复制、浅复制并不是一样的，含义是不一样的。赋值。指的是 “ 等号= ”。它相当于是给引用对象起一个别名。浅度复制和深度复制。指的是类实现 ICloneable接口，重写该接口的唯一方法。注意：不管是深度复制还是浅度复制，都是通过ICloneable接口去实现的。

值类型变量存储的是变量的值，直接储存在栈内存中。引用类型变量存储的是变量所在的内存地址，引用类型变量的实际数据存储于托管堆，变量本身仅仅是一个指向堆中实际数据的地址，存储于栈内存中，通常是四个字节。

值类型Value存储在线程堆栈中。引用类型Reference存储在托管堆上。

全局数据区：存放全局变量，静态数据，常量。代码区：存放所有的程序代码。栈区：存放为运行而分配的局部变量，参数，返回数据，返回地址等。堆区：即自由存储区

为了理解值类型变量和引用类型变量的内存分配模型，我们应先区分两种不同的内存区域——线程堆栈Thread Stack和托管堆Managed Heap。每一个正在运行的程序都对应着一个进程Process，在一个进程内部，可以有一个或多个线程Thread，每个线程都拥有一块“自留地”，成为线程堆栈,大小为1M，用于保存自身的一些数据，如函数中定义的局部变量、函数调用时传送的参数值等。现在我们可以解释第一句话——值类型存储在线程堆栈中，也就是说所有值类型的变量都是在线程堆栈中分配的。另一块内存区域称为堆Heap,在.NET这种托管环境下，堆由CLR（Common Language Runtime）管理，所以又称托管堆Managed Heap。例如使用new关键字创建类的对象实例时，分配给对象的内存单元就位于托管堆中。

1、赋值。赋值和深度复制，浅度复制完全是不同的概念，并没有什么关系，很多文章说赋值对于值类型是深度复制，对于引用类型是浅度复制，这种说法是不正确的，它的本质是在线程栈上产生一样的副本。

2、浅度复制。值类型成员独立，但是引用类型成员共享。

3、深度复制。值类型成员和引用类型成员都是独立的，即完完全全的一个全新的副本，称之为深度复制。

（1）String字符串对象是引用对象，但是很特殊，它表现的如值对象一样，即对它进行赋值，分割，合并，并不是对原有的字符串进行操作，而是返回一个新的字符串对象。但这其实是运算符重载的结果，将string实现为语义遵循一般的、直观的字符串规则。 String对象被分配在堆上,而不是栈上。

（2）Array数组对象是引用对象，在进行赋值的时候，实际上返回的是源对象的另一份引用而已；因此如果要对数组对象进行真正的复制（深拷贝），那么需要新建一份数组对象，然后将源数组的值逐一拷贝到目的对象中。

最近开始整理自己实际项目中用到的和可能用到的软件架构体系，我打算每种架构都好好写文章，并且根据自己的实际情况定制出相应的架构，我还希望把他编写成一个codesmith模板，可以实现自动化代码。前面7种是具体落地的软件架构，最后1种是架构设计思想。

1、极简数据库访问架构，这种架构非常适合编写一些小软件，里面只有一个SQLHelper文件，并且模仿三层架构，拥有DAL类和BLL类，最后加上一个程序入口Program。

2、简单三层架构，这种架构非常适合开发小型项目，web层就是MVC或者API，并且拥有BLL层和DAL层。

3、N层架构，这是一种适合大型项目的开发架构，但是更多是基于数据库构建的系统，没有基于DDD或者其他好的软件设计模式。

4、基于AutoFac、依赖注入和模板模式的多层架构。

5、基于ABP框架的架构，完全按照DDD设计模式开发，可能有些臃肿，但是非常适合大型软件和系统。

6、基于整洁架构的框架，完全按照DDD并且结合各种软件技术。

7、垂直切片架构，这是一种和传统分成架构完全不一样的架构，适合已经熟悉DDD和各种架构模式的成熟团队使用，并且适合开发微服务架构下的子系统。

8、基于清晰架构的微服务软件架构设计思想，这不是具体的实现，而只是一种架构大局观，用于指导大型的软件架构设计。

许多年前，我们开始了一个新的长期项目，首先，我们基于洋葱架构构建了它的架构。在几个月内，这种风格开始显示出裂缝，我们从这种架构转向CQRS。随着转向CQRS，我们开始围绕垂直切片而不是层（无论是平面还是同心，它仍然是层）构建我们的架构。从那以后，在过去7到8年左右的时间里，围绕垂直切片架构构建应用程序和系统的所有方式一直是我们独有的方法，我无法想象回到分层架构方法的限制。

传统的分层/洋葱/清洁架构在其目标是单体的：

这种架构方式问题是实际上只适用于系统中的少数典型请求。此外，我倾向于看到这些架构严重拟合，严格遵守依赖关系管理规则。在实践中，我发现这些规则很少有用，并且你开始得到很多关于真正不应该被抽象的抽象（控制器必须与必须使用存储库的服务进行对话）。

相反，我想对我的系统采用量身定制的方法，我将每个请求视为如何处理其代码的独特用例。因为我的系统整齐地分解为“命令”请求和“查询”请求（HTTP-land中的GET与POST / PUT / DELETE），所以向垂直切片架构的移动使我使用了CQRS。

什么是“垂直切片架构”？在这种风格中，我的架构是围绕不同的具体请求功能而构建的，通过这种方法，我们的每个垂直切片都可以自行决定如何最好地满足请求：

(对于获取订单，直接使用ORM转换为DTO，对于订单细节使用原生SQL转换为DTO，对于发票，使用基于聚合根的事件溯源，取消订单使用存储过程，这是一种微服务风格)

在所谓正常的“n层”或六边形或任何架构中，通过垂直切片移除这些层障碍，并沿着变化轴聚合在一起：

在应用程序中添加或更改功能时，通常会在应用程序中涉及到许多不同的“层”。现在改为沿着切片垂直将这些功能聚合在一起。

最小化切片之间的耦合，并最大化切片内的聚合。

通过这种方法，大多数抽象都消失了，我们不需要任何类型的“共享”层抽象，如存储库，服务，控制器。有时我们仍需要这些工具，但我们将交叉切片逻辑共享保持在最低限度。

通过这种方法，我们的每个垂直切片都可以自行决定如何最好地满足请求。

“企业架构模式”一书中的旧域逻辑模式不再需要成为应用程序范围内的选择。相反，我们可以从简单的（事务脚本）开始，并简单地重构从我们在业务逻辑中看到的代码气味中出现的模式。新功能只添加代码，您不会更改共享代码并担心副作用。非常自由！

但是，这种方法有一些缺点，因为它确实假设您的团队了解代码气味和重构。如果您的团队不理解“服务”在将逻辑推送到领域时自己却做得太多相关业务逻辑事情，那么这种模式可能不适合您。（服务类似餐厅服务员，服务员不应该做决定，只是协调者，当然如果你想退菜，服务员会决定说：不能退，菜已经烧了。）

如果您的团队确实理解了重构，并且能够识别何时将复杂的逻辑推入域，进入DDD服务应该是什么，并且熟悉其他Fowler/Kerievsky重构技术，那么您会发现这种架构风格能够远远超过传统的分层/同心架构。

来源：https://www.jdon.com/53095.html

这段时间一直在重构公司的项目代码，所以非常关注软件架构的设计，回顾我的架构接触史：第一次接触C#和.NET的时候就知道了三层架构和多层架构，当时被DAL和BLL等分层震惊了，原来软件设计还有那么多门道；毕业之后工作一直在使用多层架构，接着是MVC架构的出现，这种快速开发web站点的架构横扫整个行业；后来进入大厂工作，接触到了DDD；最近几年微服务架构又风声水起。

整体下来我最开始用了三层架构、然后是多层架构，接着是MVC架构配合多层架构，最后到了微服务架构，现在深刻理解那句话：没有最好的架构，只有最合适的架构。

网上看到有个人总结传统的架构演变之路：

三层架构：这是最简单、同时也是最成熟的软件应用程序架构，它将应用程序组织到三个逻辑和物理计算层中，包括表示层或用户界面、用于处理数据的应用(业务逻辑)程序层和用于存储和管理应用程序关联数据的数据层。大型项目中很少用，但是我还是会在一些小工具和小应用里运用。

多层架构：这种架构是三层架构的升级版，就是增加更多层对系统进行隔离，提高可扩展性和复用性，当然也增加了系统的复杂度。这是我刚毕业那家年用得最多的架构。

基于DDD的分层架构：采用领域驱动设计的思想设计的多层架构，以领域模型为核心、使用依赖注入和控制反转等技术来实现软件，对系统进行解耦，获得最大限度地可维护性和可扩展性。这是我现在在项目中用得最多的架构。

领域模型准确反映了业务语言，而传统数据对象除了简单setter/getter方法外，没有任何业务方法，即失血模型，那么DDD领域模型就是充血模型（业务方法定义在实体对象中）。首次清晰描述了领域驱动的分层实现并统一了业务语言。单一职责、低耦合、高内聚、业务内核沉淀。

六边形架构：让用户、程序、自动化测试和批处理脚本可以平等地驱动应用，让应用的开发和测试可以独立于其最终运行的设备和数据库。

左侧: 代表 UI 的适配器被称为主适配器，它们发起了对应用的一些操作，端口（应用层API）和它的具体实现(controller实现)都在应用内部。右侧: 表示和后端工具链接的适配器，被称为从适配器，它们只会对主适配器的操作作出响应，端口在应用内部(业务接口)，具体实现（impl）在应用之外。

洋葱架构：在端口和适配器架构的基础上贯彻了将领域放在应用中心，将传达机制(UI)和系统使用的基础设施(ORM、搜索引擎、第三方 API...)放在外围的思路。洋葱架构在业务逻辑中加入了一些在“领域驱动设计”中被识别出来的层次。

围绕独立的对象模型构建应用。内层定义接口，外层实现接口。依赖的方向指向圆心。所有的应用代码可以独立于基础设施编译和运行。职责分离更彻底，高内聚低耦合。更好的可测试性和可维护性。

整洁架构：这套架构是站在巨人的肩膀上，把MVC、EBI、端口适配器、洋葱架构、DDD融会贯通，形成了一套落地实践方案。

清晰架构：融合 DDD、洋葱架构、整洁架构、CQRS等一系列架构的信息，这种架构很复杂，你可以根据实际情况来选择。

微服务架构：微服务架构的诞生是因为docker的兴起，因为可以更好地管理各种部署，所以可以将一个大型系统拆分部署到docker之中，每个小服务都能实现集群部署。我个人认为并非一开始就要上微服务架构，架构是不断演化的过程，哪怕是一开始就定位很大系统，可以先划分出基本的服务就行（比如登录系统、支付中心、内容服务、接口开放平台和后台系统），更细的划分可以随着业务的发展不断演化——当然前提是要一直保证代码的整洁和简洁、遵循基本的面向对象代码原则。

垂直切片架构：我是最近才接触到了这种架构，我们的项目最近用到了MediatR和AutoMapper，这两个开源项目的作者Bogard JIMMY BOGARD在自己的项目中实现了这种架构，通过反思洋葱架构和整洁架构等各种分层和抽象得出来的一种架构，作者不建议做太多的分层，因为各种以来会导致大量的问题，作者认为在微服务架构里面特别实用，当然代码也会准从DDD的设计原则。作者认为在所谓传统正常的“N层”或六边形或任何架构中，通过垂直切片移除这些层障碍，并沿着变化轴聚合在一起：

这两周来频繁刷机，更新系统又还原系统，弄懂了很多事情，写一篇日志总结，以便以后查询使用，也希望能够看到的人能避免踩坑，也许第三部分更有价值，可以直接跳过去看。

一、关于刷机

刷机有风险，可能会变砖。不过因为很多手机都留了最后一手：FASTBOOT，所以总能把手机就回来。 刷机的有不少的方法：卡刷、线刷、OTA。卡刷：一般来说卡刷简单的能够理解为在内存卡中刷机，就是进入Recovery中刷入系统；线刷：线刷事实上能够简单的理解为用USB线刷机；OTA：仅仅要在系统中在线升级就能够成功刷机。

刷机之前需要解锁，一般开放点的厂商都会给相应的解锁工具和权限，只要愿意折腾都可以完成解锁。其实解锁和刷机就是为了获得root权限，这样可以对系统做更大的定制，当然也降低手机的安全性。

刷机要根据自己的手机型号找到相应的刷机包（也就是ROM），要注意是卡刷还是线刷，卡刷就是拷贝到手机卡里刷机，线刷就是用电脑的工具通过手机数据线刷机。

小米的MIUI系统有大量的刷机包，我一直都喜欢用欧版，地址是：https://xiaomi.eu 内网地址是：https://sourceforge.net/projects/xiaomi-eu-multilang-miui-roms/

二、获得root权限

我用的是小米手机，有两种方法，这里从别的地方搬过来，我只把重要的步骤留下，并且指出可能的坑点。

1、通过替换boot.img方式安装Magisk获取Root权限指南

来源原文：https://miuiver.com/install-magisk-for-xiaomi/

现在获取手机 Root 主要通过安装 Magisk 实现，这篇文章将以新手视角介绍如何安装使用 Magisk。

准备工作：安装 Magisk 过程中需要用到 fastboot 命令，需要刷写手机 boot 或 Recovery 分区，请确保手机已完成 BL 解锁，不然无法进行。正常情况下不会丢数据，但是建议都先外置备份手机数据再操作。

下载Magisk 地址 https://github.com/topjohnwu/Magisk/releases （选择下载最新版，然后安装到手机）。

提取相应文件：查看手机上运行的系统版本是多少，下载对应系统版本刷机包，从里面提取相应文件（请见下面说明）。如果之前 Ramdisk 查询结果为“是”，请提取 boot.img 文件如果之前 Ramdisk 查询结果为“否”，请提取 recovery.img 文件。

文件提取方法：如果系统版本有线刷包，可以直接解压提取；如果系统版本只有卡刷包，需要从解压的 payload.bin 文件里提取（老机型卡刷包可以直接提取），将提取到的文件复制到手机上。

生成修补文件：手机打开 Magisk 软件，点击 Magisk 卡片中的“安装”按钮。点击“选择并修补一个文件”，选择之前提取到的 boot.img 或 recovery.img 文件，点击“开始”，然后等待生成修补文件。据 Magisk 文档指出，小米有个别机型 Ramdisk 结果可能不能准确检测。如果修补 recovery.img 文件失败，可以尝试用 boot.img 修补，后面安装也遵循 Ramdisk 结果为“是”的做法。将生成的修补文件复制到电脑上（修补文件默认保存在手机内部存储 Download 目录）。

刷写修补文件：将手机关机，长按音量下键+电源键进入 FASTBOOT 模式，用数据线连接到电脑。电脑打开存放修补文件的文件夹，按住键盘 Shift 键，同时鼠标右键点击文件夹空白处，在右键菜单点击“在此处打开 Powershell 窗口”，然后运行下面刷写命令（命令中的文件名请先自行修改）。如果之前修补 boot.img 文件请用这个命令：.\fastboot flash boot magisk_patched-25200_pU6ZV.img；如果之前修补 recovery.img。文件请用这个命令：.\fastboot flash recovery magisk_patched-25200_pU6ZV.img。刷写完成后用下面命令重启手机：.\fastboot reboot

提示：如果刷完后遇到反复重启进不去系统问题，可以尝试先用下面命令禁用启动验证（AVB/DM-Verity），然后重复上一步骤重新刷写修补文件（这个方法仅限具有单独 vbmeta 分区的机型使用）, .\fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
命令中用到的 vbmeta.img 文件从刷机包内提取，方法和之前提取其它文件一样。

如果出现成砖或者解决不了的问题，只需用之前方法刷回从刷机包提取的原始文件boot.img。

2、小米手机刷 TWRP 方法

来源原文：https://miuiver.com/how-to-flash-twrp/

如果要刷第三方ROM，或者不能用MIUI内置卡刷功能的受限版本，唯一办法是通过安装第三方 Recovery来刷机。其中TWRP是最常使用的第三方 Recovery，官方适配了许多机型，也有不少民间修改版本。如果是发布超过一段时间的机型，通常用官方版本就可以。如果是新机，则很可能官方还没有适配，只能用第三方版。

官方和第三方版本区别是：前者不用担心安全问题，能稳定获得更新，后者则需自行判断作者可信度。第三方版本通常会自带移除 MIUI 启动验证，官方版需要手动解决这个问题（刷入 Magisk 解决），不然可能卡米无法进入系统。

最后，对于采用 A/B 分区的手机，由于后续更新系统会切换分区，这可能丢失 TWRP 安装。这种机型不建议安装 TWRP，而改为只在需要时启动它。

TWRP刷入步骤：先将手机与电脑连接以便安装好驱动（如果安装失败，可下载 MiFlash 再手动安装）。另外确保手机已完成 BL 解锁；电脑下载 Fastboot 工具（解压备用）和对应机型 TWRP（.img 后缀文件，将其放入前面解压的文件夹里，官方地址是：https://twrp.me/Devices/Xiaomi/ ）；将手机关机，长按开机键 + 音量下键进入 fastboot 模式，与电脑连接； 电脑打开刚才解压的 platform-tools 文件夹，按住 Shift 键，同时右键点击文件夹空白处，在右键菜单点击“在此处打开 Powershell 窗口”，运行下面命令刷入 TWRP（自行替换文件名）。

.\fastboot flash recovery twrp-3.7.0.img

注：如果不希望安装 TWRP，而只是临时使用 TWRP，运行下面命令（自行替换文件名）并忽略第 5 步骤。

.\fastboot boot twrp-3.7.0.img

如果运行命令后无法启动 TWRP，一直停在开机界面，可能是 TWRP 版本适配有问题，可尝试使用第三方版。

为防止重启手机 MIUI 自动替换回官方 Recovery，按住手机音量上键，同时电脑运行下面命令重启手机，直至进入 TWRP 界面。

.\fastboot reboot

在进入 TWRP 后，会询问“是否保持系统分区为只读”。这里滑动按钮以允许修改 ，不然不能禁止 MIUI 替换回官方 Recovery。滑动按钮允许 TWRP 修改 System 分区。

由于 MIUI 在启动时会检查 System 分区完整性，上一步 TWRP 修改了 System 分区，这时重启手机会无法启动系统（“卡米”问题），需要通过刷入 Magisk 移除启动验证，步骤如下：电脑下载 Magisk 安装包，将其复制到手机上（这时电脑可以识别手机 MTP 设备）；TWRP 界面上点击“安装”，找到下载的是 Magisk 安装包，点击文件名，滑动按钮刷入；等待 Magisk 刷入完成，点击“重启系统”，这时就不会有“卡米”问题，重启手机也不会丢失 TWRP 安装。

3、MIUI欧洲版或者国际版刷本土模块

通过上面的两个步骤获得root权限并且装上Magisk之后，就可以刷入本土包了，比如钱包里的公交卡和门禁卡等。

只要刷入相应的模块就可以，这里有人专门做了相应的模块包，链接直达：https://blog.minamigo.moe/archives/184 ，作者在github创建了一个项目，主要是在为Miui Eu用户恢复Miui大陆版的功能。Miui Eu用户可通过使用此项目，同时获取Miui Eu的功能和Miui大陆版的功能。其实我只需要钱包，其他都没必要，原因你懂的。

这个包是为miui13和miui14专门写的程序，不过我试过miui12、miui11都能安装，至少钱包可以，其他没有验证过。

三、我踩过的坑

1、TWRP官方版本最新程序是3.7.0（截至到2023年2月15日），目前只支持android12，不支持android13，所以如果你更新的系统是13，那么你就可以放弃获得root或者按照magisk了。不过对于一些小米机型，有高人自己改写了twrp，但是要注意：这不是官方的，一点要慎重，地址是：https://www.123pan.com/s/qHhDVv-nuQJv 作者是活跃在xiaomi.eu上面的会员，可以点击这里：https://xiaomi.eu/community/members/gogocar62.295691/ 查看他的信息。

2、线刷的时候路径不要太长，否则就刷机不成功，因为很多安装包下载的时候文件名都特别长，把文件夹名称修改为短一点的就行，比如rom。

3、现在很多手机都采用 Virtual A/B 分区，这种情况如果刷入twrp，可能你会不小心切换到不同的分区，比如slot A和slot B，很多人一看就英文就乱点。可能你不小心就进入另外一个槽位，那么手机会无线进入fastboot，这时候需要在fastboot模式下运行：.\fastboot set_active b，也就是把B槽位弄成活跃槽位(也可能要把A槽设置为活跃槽位：.\fastboot set_active a，具体看系统安装在哪里)，然后重启手机到system。

4、刷机包ROM必须要对应自己的硬件，可以通过官方名，比如MI12，或者MI12 Lite之类的查找，不过一般都会有一个英文代号，刷机包不对肯定搞不定，包括获取boot.img，别抱侥幸心理，系统都是针对硬件定制开发，多一行代码都没法运行。

5、这是最后一条：必须备份数据！必须备份数据！！必须备份数据！！！哪怕你觉得自己很熟悉，甚至自己曾经走过同样的路径，总会有意想不到的事情发生。

string是开发过程中，使用频度最高的类型之一，所以在构建类型时作了很多处理，如“不可变性”，“保留性”等特点。string的常量是在""引号中进行赋值的。

var str1 = "这是一段文字";
Console.WriteLine(str1);

为了字符串的格式化，引入了$""定义方式，这样就可以在字符串中用{}来标注格式化的内容了。

var str2 = $"时间：{DateTime.Now}";
Console.WriteLine(str2);
//输出结果是：时间：1/6/2023 15:37:13

var str2_1 = $"时间：{DateTime.Now:yyyy-MM-dd}";
Console.WriteLine(str2_1);
//输出结果是：时间：2023-01-06

为了解决字符串内容的换行，引定入@""，来定义有换行的字符串，比如下面的一条SQL查询，可以按格式化后的样式来定义。$和@可以混用，不分先后。

var str3 = @"SELECT ID
    ,Question
    ,Score
    ,QuestionTypeID
    ,SubjectTypeID
    FROM Questions";
Console.WriteLine(str3);

var str3_1 = @$"SELECT ID
    ,Question
    ,Score
    ,QuestionTypeID
    ,SubjectTypeID
    FROM Questions WHERE Score>{10}";
Console.WriteLine(str3_1);

其实原始字符串还解决了一个问题，就是字符串中有"的问题，以前需要有转义字符来实现，现在原始字符串都搞定了。

Console.WriteLine("\"a\" 是小写的");//通过\来转义
Console.WriteLine(@"""a"" 是小写的");//前缀是@时，通过"转义

最佳demo是json字符串的定义，用原始字符串的方式定义json字符串，最合适不过了。

var jsonString = """
                 {
                     "irstName": "John",
                     "astName": "Smith",
                     "ex": "male",
                     "ge": 25,
                     "ddress": 
                     {
                         "treetAddress": "21 2nd Street",
                         "ity": "New York",
                         "tate": "NY",
                         "ostalCode": "10021"
                     }
                 }
                 """;

Console.WriteLine(jsonString)

通过下图，看到的json原始字符串，一目了然：

作为一个软件开发者，你一定会对网络应用如何工作有一个完整的层次化的认知，同样这里也包括这些应用所用到的技术：像浏览器，HTTP，HTML，网络服务器，需求处理等等。

本文将更深入的研究当你输入一个网址的时候，后台到底发生了一件件什么样的事

1 首先，你得在浏览器里输入要网址:

2 浏览器查找域名的IP地址

导航的第一步是通过访问的域名找出其IP地址。DNS查找过程如下：

浏览器缓存 – 浏览器会缓存DNS记录一段时间。 有趣的是，操作系统没有告诉浏览器储存DNS记录的时间，这样不同浏览器会储存个自固定的一个时间（2分钟到30分钟不等）。

系统缓存 – 如果在浏览器缓存里没有找到需要的记录，浏览器会做一个系统调用（windows里是gethostbyname）。这样便可获得系统缓存中的记录。

路由器缓存 – 接着，前面的查询请求发向路由器，它一般会有自己的DNS缓存。
ISP DNS 缓存 – 接下来要check的就是ISP缓存DNS的服务器。在这一般都能找到相应的缓存记录。

递归搜索 – 你的ISP的DNS服务器从跟域名服务器开始进行递归搜索，从.com顶级域名服务器到Facebook的域名服务器。一般DNS服务器的缓存中会有.com域名服务器中的域名，所以到顶级服务器的匹配过程不是那么必要了。DNS递归查找如下图所示：

DNS有一点令人担忧，这就是像wikipedia.org 或者 facebook.com这样的整个域名看上去只是对应一个单独的IP地址。还好，有几种方法可以消除这个瓶颈：

循环 DNS 是DNS查找时返回多个IP时的解决方案。举例来说，Facebook.com实际上就对应了四个IP地址。

负载平衡器 是以一个特定IP地址进行侦听并将网络请求转发到集群服务器上的硬件设备。 一些大型的站点一般都会使用这种昂贵的高性能负载平衡器。

地理 DNS 根据用户所处的地理位置，通过把域名映射到多个不同的IP地址提高可扩展性。这样不同的服务器不能够更新同步状态，但映射静态内容的话非常好。

Anycast 是一个IP地址映射多个物理主机的路由技术。 美中不足，Anycast与TCP协议适应的不是很好，所以很少应用在那些方案中。大多数DNS服务器使用Anycast来获得高效低延迟的DNS查找。

3 浏览器给web服务器发送一个HTTP请求

因为像Facebook主页这样的动态页面，打开后在浏览器缓存中很快甚至马上就会过期，毫无疑问他们不能从中读取。

所以，浏览器将把一下请求发送到Facebook所在的服务器：

GET http://facebook.com/ HTTP/1.1
 Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
 Accept-Encoding: gzip, deflate
 Connection: Keep-Alive
 Host: facebook.com
 Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

GET 这个请求定义了要读取的URL： “http://facebook.com/”。 浏览器自身定义 (User-Agent 头)， 和它希望接受什么类型的相应 (Accept and Accept-Encoding 头). Connection头要求服务器为了后边的请求不要关闭TCP连接。

请求中也包含浏览器存储的该域名的cookies。可能你已经知道，在不同页面请求当中，cookies是与跟踪一个网站状态相匹配的键值。这样cookies会存储登录用户名，服务器分配的密码和一些用户设置等。Cookies会以文本文档形式存储在客户机里，每次请求时发送给服务器。

用来看原始HTTP请求及其相应的工具很多。作者比较喜欢使用fiddler，当然也有像FireBug这样其他的工具。这些软件在网站优化时会帮上很大忙。

除了获取请求，还有一种是发送请求，它常在提交表单用到。发送请求通过URL传递其参数(e.g.: http://robozzle.com/puzzle.aspx?id=85)。发送请求在请求正文头之后发送其参数。

像“http://facebook.com/”中的斜杠是至关重要的。这种情况下，浏览器能安全的添加斜杠。而像“http: //example.com/folderOrFile”这样的地址，因为浏览器不清楚folderOrFile到底是文件夹还是文件，所以不能自动添加 斜杠。这时，浏览器就不加斜杠直接访问地址，服务器会响应一个重定向，结果造成一次不必要的握手。

4 facebook服务的永久重定向响应

图中所示为Facebook服务器发回给浏览器的响应：

HTTP/1.1 301 Moved Permanently
 Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
 pre-check=0
 Expires: Sat, 01 Jan 2000 00:00:00 GMT
 Location: http://www.facebook.com/
 P3P: CP="DSP LAW"
 Pragma: no-cache
 Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
 path=/; domain=.facebook.com; httponly
 Content-Type: text/html; charset=utf-8
 X-Cnection: close
 Date: Fri, 12 Feb 2010 05:09:51 GMT
 Content-Length: 0

服务器给浏览器响应一个301永久重定向响应，这样浏览器就会访问“http://www.facebook.com/” 而非“http://facebook.com/”。

为什么服务器一定要重定向而不是直接发会用户想看的网页内容呢？这个问题有好多有意思的答案。

其中一个原因跟搜索引擎排名有 关。你看，如果一个页面有两个地址，就像http://www.igoro.com/ 和http://igoro.com/，搜索引擎会认为它们是两个网站，结果造成每一个的搜索链接都减少从而降低排名。而搜索引擎知道301永久重定向是 什么意思，这样就会把访问带www的和不带www的地址归到同一个网站排名下。

还有一个是用不同的地址会造成缓存友好性变差。当一个页面有好几个名字时，它可能会在缓存里出现好几次。

5浏览器跟踪重定向地址

现在，浏览器知道了“http://www.facebook.com/”才是要访问的正确地址，所以它会发送另一个获取请求：

GET http://www.facebook.com/ HTTP/1.1
 Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
 Accept-Language: en-US
 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
 Accept-Encoding: gzip, deflate
 Connection: Keep-Alive
 Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]
 Host: www.facebook.com

头信息以之前请求中的意义相同。

6. 服务器“处理”请求

服务器接收到获取请求，然后处理并返回一个响应。

这表面上看起来是一个顺向的任务，但其实这中间发生了很多有意思的东西- 就像作者博客这样简单的网站，何况像facebook那样访问量大的网站呢！

Web服务器软件

web服务器软件（像IIS和阿帕奇）接收到HTTP请求，然后确定执行什么请求处理来处理它。请求处理就是一个能够读懂请求并且能生成HTML来进行响应的程序（像ASP.NET,PHP,RUBY...）。举个最简单的例子，需求处理可以以映射网站地址结构的文件层次存储。像http://example.com/folder1/page1.aspx这个地 址会映射/httpdocs/folder1/page1.aspx这个文件。web服务器软件可以设置成为地址人工的对应请求处理，这样 page1.aspx的发布地址就可以是http://example.com/folder1/page1。

请求处理

请求处理阅读请求及它的参数和cookies。它会读取也可能更新一些数据，并讲数据存储在服务器上。然后，需求处理会生成一个HTML响应。
所 有动态网站都面临一个有意思的难点 -如何存储数据。小网站一半都会有一个SQL数据库来存储数据，存储大量数据和/或访问量大的网站不得不找一些办法把数据库分配到多台机器上。解决方案 有：sharding （基于主键值讲数据表分散到多个数据库中），复制，利用弱语义一致性的简化数据库。

委托工作给批处理是一个廉价保持数据更新的技术。举例来讲，Fackbook得及时更新新闻feed，但数据支持下的“你可能认识的人”功能只需要每晚更新 （作者猜测是这样的，改功能如何完善不得而知）。批处理作业更新会导致一些不太重要的数据陈旧，但能使数据更新耕作更快更简洁。

7 服务器发回一个HTML响应

图中为服务器生成并返回的响应：

HTTP/1.1 200 OK
 Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
 pre-check=0
 Expires: Sat, 01 Jan 2000 00:00:00 GMT
 P3P: CP="DSP LAW"
 Pragma: no-cache
 Content-Encoding: gzip
 Content-Type: text/html; charset=utf-8
 X-Cnection: close
 Transfer-Encoding: chunked
 Date: Fri, 12 Feb 2010 09:05:55 GMT

整个响应大小为35kB，其中大部分在整理后以blob类型传输。

内容编码头告诉浏览器整个响应体用gzip算法进行压缩。解压blob块后，你可以看到如下期望的HTML。

关于压缩，头信息说明了是否缓存这个页面，如果缓存的话如何去做，有什么cookies要去设置（前面这个响应里没有这点）和隐私信息等等。

请注意报头中把Content-type设置为“text/html”。报头让浏览器将该响应内容以HTML形式呈现，而不是以文件形式下载它。浏览器会根据报头信息决定如何解释该响应，不过同时也会考虑像URL扩展内容等其他因素。

8 浏览器开始显示HTML

在浏览器没有完整接受全部HTML文档时，它就已经开始显示这个页面了：

9 浏览器发送获取嵌入在HTML中的对象

在浏览器显示HTML时，它会注意到需要获取其他地址内容的标签。这时，浏览器会发送一个获取请求来重新获得这些文件。

下面是几个我们访问facebook.com时需要重获取的几个URL：

图片
http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif
http://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif
…
CSS 式样表
http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css
…
JavaScript 文件
http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js
…
这些地址都要经历一个和HTML读取类似的过程。所以浏览器会在DNS中查找这些域名，发送请求，重定向等等...

但 不像动态页面那样，静态文件会允许浏览器对其进行缓存。有的文件可能会不需要与服务器通讯，而从缓存中直接读取。服务器的响应中包含了静态文件保存的期限 信息，所以浏览器知道要把它们缓存多长时间。还有，每个响应都可能包含像版本号一样工作的ETag头（被请求变量的实体值），如果浏览器观察到文件的版本 ETag信息已经存在，就马上停止这个文件的传输。

试着猜猜看“fbcdn.net”在地址中代表什么？聪明的答案是"Facebook内容分发网络"。Facebook利用内容分发网络（CDN）分发像图片，CSS表和JavaScript文件这些静态文件。所以，这些文件会在全球很多CDN的数据中心中留下备份。

静态内容往往代表站点的带宽大小，也能通过CDN轻松的复制。通常网站会使用第三方的CDN。例如，Facebook的静态文件由最大的CDN提供商Akamai来托管。

举例来讲，当你试着ping static.ak.fbcdn.net的时候，可能会从某个akamai.net服务器上获得响应。有意思的是，当你同样再ping一次的时候，响应的服务器可能就不一样，这说明幕后的负载平衡开始起作用了。

10浏览器发送异步（AJAX）请求

在Web 2.0伟大精神的指引下，页面显示完成后客户端仍与服务器端保持着联系。

以 Facebook聊天功能为例，它会持续与服务器保持联系来及时更新你那些亮亮灰灰的好友状态。为了更新这些头像亮着的好友状态，在浏览器中执行的 JavaScript代码会给服务器发送异步请求。这个异步请求发送给特定的地址，它是一个按照程式构造的获取或发送请求。还是在Facebook这个例 子中，客户端发送给http://www.facebook.com/ajax/chat/buddy_list.php 一个发布请求来获取你好友里哪个 在线的状态信息。

提起这个模式，就必须要讲讲"AJAX"-- “异步JavaScript 和 XML”，虽然服务器为什么用XML格式来进行响应也没有个一清二白的原因。再举个例子吧，对于异步请求，Facebook会返回一些JavaScript的代码片段。

除了其他，fiddler这个工具能够让你看到浏览器发送的异步请求。事实上，你不仅可以被动的做为这些请求的看客，还能主动出击修改和重新发送它们。AJAX请求这么容易被蒙，可着实让那些计分的在线游戏开发者们郁闷的了。（当然，可别那样骗人家~）

Facebook聊天功能提供了关于AJAX一个有意思的问题案例：把数据从服务器端推送到客户端。因为HTTP是一个请求-响应协议，所以聊天服务器不能把新消息发给客户。取而代之的是客户端不得不隔几秒就轮询下服务器端看自己有没有新消息。

这些情况发生时长轮询是个减轻服务器负载挺有趣的技术。如果当被轮询时服务器没有新消息，它就不理这个客户端。而当尚未超时的情况下收到了该客户的新消息，服务器就会找到未完成的请求，把新消息做为响应返回给客户端。

总结一下

希望看了本文，你能明白不同的网络模块是如何协同工作的.