A protocol is a set of rules and procedures computers over a network use to communicate with each other. # Communications Protocols ## Internet Protocol **IP**, uses either TCP or UDP as is necessary.  A device gets a unique identity (IPv4 or IPv6) to ensure reliable communication. ## TCP Protocol Transmission Control Protocol – The Server sends information, and never confirms if it was received.  Simplest and fastest, but also easy to intercept without anyone knowing. ## UDP Protocol User Datagram Protocol – The Server sends information, confirms it was received, and reacts if it didn’t.  Most reliable, and still can be intercepted, but at least someone will be able to tell if the wrong message got there. ## DNS Domain Name Service – provides a “nickname” for an IP address. # Data Transfer Protocols ## FTP – File Transfer Protocol – simplest way to send files. 1. A command provides instructions on sending a file 2. The FTP Client then sends the file via TCP to the destination. 3. A command asks for an updated filelist from the Recipient. 4. A command then gets an updated file list from the FTP Recipient via TCP communication. ## HTTP – Hypertext Transfer Protocol – “The Internet Protocol” 1. A Client (browser) sends a Domain Name Search request to a DNS. 2. The DNS Responds with an IP Address. 3. The client sends a GET request to the IP Address. 4. The Server responds with a SEND response 5. The client interprets the SEND response and displays it in the browser. ## More Data Transfer Protocols - SMTP – Simple Mail Transfer Protocol - POP3 – Post Office Protocol (version 3) - IMAP4 – Internet Message Access Protocol (version 4) - RTMP – Real Time Messaging Protocol - **HTTPS – Hypertext Transfer Protocol Secure** – The Newest Protocol, slower, but safer from interception - TSL, Transport Security Layer, once referred to as SSL (Secure Sockets Layer), requires the server provide a certificate of authenticity. # The TLS Handshake Process |Step|For Dummies|Slightly More Technical| |-|-|-| |1|The Client extends their hand.|The Client says “Hello”.  Literally.| |2|The Server extends their hand very openly with a unique grip.|The Server says “Hello” back.  But the server says “Hello” with a Certificate.| |3|The Client looks at their hand to make sure it’s actually attached to the correct person’s arm.|The Client looks at the Certificate and checks with the Certificate Authority to see if it’s legitimate.  If not, it runs away.| |4|The Client matches their hand to the unique grip of the Server.|The Client uses the Public Key from the Certificate to send an encrypted message called the Premaster Secret.| |5|The Server clasps the Clients hand, and hope the grips match.|The Server uses a Private Key connected to its Certificate to decrypt the Premaster Secret message.| |6|The Client and the Server both start to “bounce” their hand in unison.|While this encrypted messaging happens, both the Client and the Server generate Session Keys from the Premaster Secret and Certificate Messages.| |7|If the Client feels like the “bounce” made sense, it initiates it’s move in the secret handshake.|If the Client’s Keys matched the way they’re supposed to, they send a “Finished” message to the Server.| |8|If the Server feels like the “bounce” made sense, it initiates it’s move in the secret handshake.|The Server sends back a “Finished” message if everything checks out.| |9|So far everything is, good, so they continue the rest of the handshake, talking the entire time.|Now standard HTTP messages can be sent, all encrypted and layered with the Session Keys.| # Client-Side Processing If you don’t want the server to do the work, make the Client (browser, FTP Client, etc.) do the work.  This is called **Client-Side Processing**. Nearly every basic static website uses Client-Side Processing. 1. *A Server receives the GET request from the Client, and sends data.* It may send an HTML file, an mp3 file, a JPG file, or other such data. It may also send an accompanying CSS file, which tells the Client how to interpret the files being sent. 2. *The Client-Side takes all that data and interprets it directly on the device.*  The Server never processes a thing. A server may send “Cookies” to the Client-Side that includes data for the Client to process so that the Server doesn’t have to, such as preferred settings. 3. If an error occurs, it only messes up on the Client Side. # Server-Side Processing If you need to pull data that is stored on the server, or accessible someplace else on the Internet, you will likely need Server-Side Processing.  Oftentimes used for securely stored information that you don’t want to transmit. Most dynamic websites use Server-Side Processing to some extent. 1. *The Client sends a GET request to the Server, oftentimes with specific parameters*. 2. *The Server takes that GET request and connects it to data it has access to*, but doesn’t send the data right away.  Instead, it processes the data in a way that was requested by the Client. 3. *The Server sends the results, not the original data*. 4. *Data can be also be added to or edited when its stored on the Server*. The Client sends a POST, PUT or DELETE request to the Server, asking it to do something to the data using new data the Client sends.  This oftentimes includes authentication to ensure the Client is allowed to make the request. The Server takes the parameters from the POST, PUT or DELETE request and stores it appropriately to its data. The Server sends a message back indicating whether or not it was successful which may include similar data to what would be sent for a GET request. 5. If an error occurs, it messes up the Server Side’s processing ability, which may in turn affect the Client.