I have covered the general block structure on the BranchCache last time, this time I will look at how BranchCache works with different protocols.
Before we bring BranchCache into the picture, let us look at what has been composed with the SMB service. From the server side we have the SMB Server Driver (SMB Kernal Mode driver) and on the client we have the SMB Client Driver, CSC service (Client side caching server and it is a usermode service), csc driver and the CSC Cache itself.
With the Windows 7 and Windows server 2008 R2, the SMB server introduced two additional components; a SMB Hash Generation Service and a HashGen Utility to generate hashes. The objective is the ability to calculate hashes and send the hashes content list instead of sending the whole data back so the client's BranchCache component can locate the data.
Let's see how things work with the SMB integration. From the diagram above, starting from the left, an application is requiring a ReadFile request. The CSC driver will check the server being requested is far away from the network, if it is not, the system will get those data from the server directly without any BranchCache interference. The conditions to determine this, is based on the latency. By default, it is set at around 80ms, anything above that, the system will bring in BranchCache. If the server is far i.e. latency is high, a request is sent to the client's CSC service and sends a request hashes to the SMBClient driver. The client then will send a request to the server to get the data hashes. The Server will get the Access hashes and return it to the client driver. Once the SMBClient has the hashlist it will pass the list to branchcache. From this, the Branchcache will find the data itself from different local peers and send the data back to the CSC driver. At this moment the CSC driver will write those data to the CSC Cache itself and the data to the application at the same time. The reason the data is being written at the CSC Cache at the same time is, that any same request from the future, data hash and data itself will be sent to the client from the CSC Cache directly, up until the data is altered (i.e. different hash value then the whole process will repeat itself).
For http request, the procedure is slightly different but the fundamental remains the same.
The diagram illustrates how the BranchCache integration with the http request. The left side is the client and the right side is the server. Let's start off from the left, IE is requesting an URL from a server. Before this request reaches the server, IE will pass this request to the Wininet component. The Wininet will talk the IIS web server for the request and at the same time the Wininet will indicate that the client has the BranchCache capability. The http.sys on the server makes notes of the clients' new capability and will do something about it. Before sending the requested data, the server will do the usual authorization to ensure the user is authorized to view the data. Up to this point BranchCache is not even on the picture yet. If the client is authorized to get those data, the http.sys will bring in the BranchCache component and send those request data to the BranchCache in order to send the BranchCache data identifier back to the client. Once this is done the BranchCache will divide the data into different hashes like I mentioned in my last post; a hashlist will be sent back to the http.sys and back to the client wininet component subsequently. The Wininet then passes this hashlist to the client BranchCache component, and it will do a lookup within the local network and look for a peer or peers that has/have the data. Once the BranchCache has located these data, it will establish one or multi connection to these peers to get the actual data. Once it gets the data, it validates the data received from these peers, it will then compute the hash on the block to ensure it matches the hash that the server sent to the client to ensure the data has not been tempered with.
What happens if the data is a SSL requests. This can be https or a TLS on SMB but either one the theory remains the same. Let us look at the https example.
A client sends request from a server (IIS), the server will send the data. At this moment the data is still in clear. Banchcache will do its magic at this layer since it is still in the clear with those hashlist generated like it used to be. After that, all these data will be encrypted through SSL component. Once the data is encrypted it will send through the network to the client through the sockets layer. Remember, all data are still encrypted. Once the client has received all these data through the Sockets layer, it will pass to the SSL layer and decrypt those data and then pass on to the http layer. This is where the BranchCache component on the client does its magic and requests all the data from a local peer or peers. It does all the usual security check on the data hash and then pass on to the Broswer IE.
As you can see, this is completely transparent and eliminates any problem that normally happens by using any hardware Wide Area Network Accelerator device for SSL senarios. Normally with these WAN devices, an independent PKI infrastructure is required to encrypt and decrypt data between networks that causes a lot of problems and have higher possibility for security compromise.
As you can see from my last 3 posts, by using BranchCache from Windows 7 and Windows Server 2008R2, companies can improve company branches experience or any low bandwidth environment scenarios. The beauty with BranchCache is, it is so transparent and simple to manage that users can benefit straight away. Unlike any other form of WAN accelerator device on the market, it provides excellent security measures. Please take some time to check this tool out.
Microsoft Hong Kong