This file has been truncated. show original
# Scalable HTTP sockets for the cloud, Part 2
In this article we will expand on our TgoHttpClient class by adding some core new features including non-blocking http responses, unifying HTTP 1.1, HTTP/S and HTTP/2 support into a common class, incremental data transfers, various fixes and performance improvements.
[In a previous article](https://blog.grijjy.com/2017/01/09/scalable-https-and-tcp-client-sockets-for-the-cloud/) we discussed the scalable client socket problem and how it creates a bottleneck for services that need to communicate over TCP as a client socket. This model is common in backend services when you interact with third-party providers such as databases, remote push notification services (Apple or Google) or just about any JSON/REST based HTTP API.
If you use a typical HTTP client or component in your Windows or Linux service, you are almost always using [Berkeley based sockets](https://en.wikipedia.org/wiki/Berkeley_sockets). There are numerous scale issues presented by the Winsock stack under Windows including port limitations, connection timeout retry and delay limitations, page pool issues and much more. As discussed previously, most of these limitations are worked around in Windows by using Windows IO Completion Ports (IOCP). IOCP has been available for quite some time but it is notoriously difficult to use and has been almost exclusively used for creating server applications for TCP sockets.
IOCP is well designed solution to scalable client sockets but it is rarely used as a foundation model that allows you to build client sockets for other protocols. In our previous article on [Scalable HTTP/S and TCP client sockets for the cloud](https://blog.grijjy.com/2017/01/09/scalable-https-and-tcp-client-sockets-for-the-cloud/), we demonstrated how to build a foundation class that uses IOCP to create client socket protocols with a brief examination of the HTTP protocol.
> This foundation model could easily be expanded and future client protocols and the apps that rely upon them could operate without modification on other operating systems such as Linux. Internally we have done this on Linux directly using FPC and Lazarus and hope to soon demonstrate this running for Linux on the latest Delphi compilers.
IOCP is at the heart of how Windows IIS operates in conjunction with the HTTP.SYS kernel driver and scales up efficiently. On Linux we have similar technologies such as EPOLL and KQueue and they are widely utilized in server based sockets. These technologies are also a perfect match for client based socket issues.
The TgoHttpClient class demonstrates how you can leverage IOCP and our foundation class TgoSocketConnection to create client sockets for the purpose of HTTP and take advantage of the many benefits of IOCP at the same time.
## Non-blocking HTTP
IOCP is designed to be non-blocking and handle numerous activities simultaneously. This is due to the fact that IOCP operations occur within a thread pool.