This post is part of a <a href="\/topics\/wordpress-tips\/developers\/" target="_blank" rel="noopener noreferrer">series<\/a> designed to help developers who are just starting out understand some basics and how they relate to WordPress. This second post is about HTTP (including its cousin, the secure version) and will attempt to explain the difference between the two and why they matter if you're developing a WordPress site.\r\n\r\nLet's start with HTTP since it's the more common. HTTP stands for <strong>Hypertext Transfer Protocol<\/strong> and is a system for transmitting and receiving information across the internet. In this case, the word <strong>protocol<\/strong> is being used to mean a rule or system of rules for the correct conduct and procedures to be followed. It is defined differently in other fields and contexts (such as law) so ignore those definitions for now.\r\n\r\nHTTP serves as a request\/response procedure that all internet agents follow so that data can be passed between servers\/nodes and clients rapidly. It's most commonly used to access HTML pages on the web but can also be used for other things. But what if you need to exchange confidential or sensitive information between server and client? That's where cousin HTTPS, which was created by Netscape way back in 1994 for its Navigator browser, comes in.\r\n\r\nHTTPS stands for <strong>Hypertext Transfer Protocol Secure<\/strong> and can be thought of as "secure HTTP." It is identical to HTTP in many ways since it follows the same basic protocols. The client (e.g. web browser) establishes a connection to a server on a standard port. When servers get requests they reply with statuses and messages, which usually contain the requested info but sometimes they send back an error if they can't figure out what the client\/browser was asking for. Both HTTP and HTTPS use the same <strong>Uniform Resource Identifier (URI)<\/strong>, and that extra S at the end which stands for secure indicates that an encrypted connection is desired.\r\n\r\nThe default port for HTTP is 80 while it's 443 for HTTPS. Ports are like locations or holes for data to enter. Think of them like boat docks. Each has a unique number, and things get routed to the right one based on established rules. HTTPS connections are encrypted so that, in theory, nobody can access the data being transmitted other than the client\/server talking to each other. Encryption just means encoding messages so that only the parties talking can understand it. Think of it as a secret language but with data (not verbal tones).\r\n\r\nThere are 2 types of encryption layers: <strong>TLS and SSL<\/strong>. You've likely heard of SSL but maybe not TLS. TLS stands for <strong>Transport Layer Security<\/strong> while SSL stands for <strong>Secure Sockets Layer<\/strong>. When responding to an HTTPS connection request, the server offers a list of encryption methods it supports. The client\/browser then picks one and they begin the information exchange. They have to agree on the method first, obviously, so they're both on the same page (no pun intended). At this point, they also exchange certificates so they know who they're dealing with. Think of certificates as passports or driver's licenses.\r\n\r\nThe parties at this point ensure they are using the same key and that the connection is closed so that nobody is peeking. Information begins to flow between them. A server needs a public key certificate to have HTTPS connections and it contains key info along with verification of its owner's identity. <strong>Certificates<\/strong> are often issued\/verified by a third-party so that they can be trusted. That's why you purchase SSL certificates for example from places like Comodo and don't make your own.\r\n\r\nSo when does using HTTPS make sense with WordPress? If you have a page and you're capturing sensitive information via forms (e.g. credit application that has a field for social security #) or if you're running eCommerce checkout on your own domain (rather than sending them off to PayPal.com) since that requires the transmission of sensitive stuff like credit card info. Even if you're using a third-party like Authorize.Net you still need to have an <strong>SSL Certificate<\/strong> to encrypt the connection if the checkout is on your domain.\r\n\r\nHere at Pagely, we allow SSLs for any client who wants one. We also have <a href="https:\/\/pagely.com\/blog\/pagely-new-features\/">an intuitive certificate manager<\/a> to walk you through the upload process. You can also use a GUI to set parameters like redirect and TLS version\/cipher.\r\n\r\nSome may worry that running SSL on your non-sensitive info pages may slow them down a tad. An SSL handshake assumes four requests for establishing a connection whereas with HTTP it's typically just one. That makes the first request four times longer, if not subsequent requests. But Pagely's <a href="https:\/\/pagely.com\/blog\/ares-application-gateway-wordpress\/">new ARES application<\/a> has faster page loads, improved up to 140% in full-page rendering times. You'll notice that we run our entire site via HTTPS, and it's very fast. If you are interested in activating ARES on your Pagely account, <a href="https:\/\/pagely.com\/blog\/new-atomic-beta-release-1\/">here is a guide<\/a>.\r\n\r\n<strong>Server Name Indication<\/strong> <strong>(SNI)<\/strong> is a final important topic and it's an extension of the TLS protocol. It indicates which hostname is being contacted by the browser at the start of the handshake process. This allows a server to connect multiple SSL certificates to one IP address and gate. This is important because IP addresses are limited, and without SNI we'd run into a major problem since sites that want to run SSL are required to have their own dedicated IP. Browsers that support SNI will immediately give the name of the site they're trying to connect with during the secure connection initialization so the server knows which certificate to send back. Visitors will not notice any difference as all of this takes place in the background. The only real downside is that older browsers and systems don't support it. There are various estimates out there, but something like 98% of all visitors should be fine if you're running SNI. That number will continue to grow as older browsers and operating systems die off.