Sockets and Networking

Talking HTTP with Python treated a web server as an object. requests.get returned a response, a Session carried the login, a status code told the script what happened. What that lesson never showed is the thing requests opens underneath every one of those calls. A socket. nmap opens one. A browser opens one. So does the ssh command and every mail client on the machine. Strip away the library and every network tool is doing the same four steps to a socket: create it, connect it, move bytes through it, close it.

The reason to open one by hand is that not everything speaks HTTP, and sometimes the exact bytes on the wire are the point. requests will not connect to an SSH server or a database. A raw socket connects to anything listening on a TCP port, and it hands back precisely what the service said, byte for byte, with no library deciding what matters.

A socket is an object with four steps

A socket is one endpoint of a network conversation, the same word TCP, UDP, and Ports defined as an IP address paired with a port. In Python it is also a literal object, built by the socket module. That module ships with the language, so there is no pip3 install the way requests needed one. A single import and it's there.

Creating the object takes two arguments that name the kind of socket to build:

import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.settimeout(3)
s.connect(("10.10.10.1", 22))
print("connected")
s.close()

AF_INET is the address family, and it means IPv4, the 10.10.10.1 style of address. SOCK_STREAM is the socket type, and it means TCP. That second constant is the whole difference between this and a UDP socket: swap in SOCK_DGRAM and the object speaks UDP instead, with all the no-handshake, no-guarantee behavior the networking module warned about. For everything in this module, SOCK_STREAM is the right choice.

The address goes into connect as one argument, a tuple of host and port. The double parentheses are not a typo. The outer pair is the function call, and the inner pair builds the (host, port) tuple that connect expects as a single value. The host is a string, either an IP or a name Python will resolve. The port is a plain integer.

Here is the part that matters, and it's the bridge back to the networking module. connect is not a local operation that flips a flag. It runs the TCP three-way handshake. Python's socket sends the SYN, waits for the SYN-ACK, and sends the ACK, the exact three messages TCP, UDP, and Ports walked through on paper. When connect returns without raising anything, all three completed. That is the precise definition of an open port: a program was listening and it finished the handshake. Five characters of Python stand in for the whole exchange. close tears the connection back down when the work is finished.

settimeout(3) is the line that beginners skip and then wonder why a script hangs. It sets a ceiling, in seconds, on how long connect and later recv will wait. Without it, a connect to a host that never answers blocks until the operating system exhausts its own retries, which on Linux can run well past a minute for a single port. Three seconds is generous for a real connection and plenty for a lab.

Sockets move bytes, not strings

A Python string is text. A socket carries raw bytes. Those are two different types, and the socket module never blurs them, which is the first thing that trips people coming from requests, where everything looked like a string. Data sent through a socket goes out as bytes, and data read back arrives as bytes.

The b prefix on a literal is how Python writes bytes instead of text: b"HEAD" is four bytes, "HEAD" is a string. A socket sends with sendall, which takes bytes, and reads with recv, which returns bytes. The number handed to recv is the maximum to pull in one read, a buffer size, not a promise of how much will arrive. If the service sends more than that ceiling, the leftover bytes wait for the next recv call.

Many services announce themselves the instant a connection opens. The server speaks first, before the client says anything. SSH does this, and so do FTP and plenty of mail servers. That opening line is the banner, and it's often the single most useful piece of reconnaissance a port gives up, because it names the software and frequently the version.

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.settimeout(3)
s.connect(("10.10.10.1", 22))
banner = s.recv(1024)
print(banner.decode(errors="ignore"))
s.close()

The .decode(errors="ignore") turns the raw bytes into a readable string. errors="ignore" tells Python to drop any byte that is not valid text instead of crashing on it, which matters because a banner can carry stray non-text bytes that would otherwise raise an exception and kill the script. The shell has a one-line version of this whole program, worth knowing because it does the same thing:

$nc 10.10.10.1 22

HTTP is the opposite case. A web server says nothing on connect. It waits for the client to send a request first, exactly the request that requests built automatically in the last lesson. Spelled out in raw bytes, that request looks like this:

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.settimeout(3)
s.connect(("10.10.10.1", 80))
s.sendall(b"HEAD / HTTP/1.0\r\n\r\n")
print(s.recv(2048).decode(errors="ignore"))
s.close()

The \r\n\r\n at the end is load-bearing. \r\n is a carriage return plus a line feed, the line ending HTTP requires, and the doubled pair is the blank line that marks the end of the request. Leave it off and the server keeps waiting for more, the recv hits its timeout, and the script prints nothing. Protocols are strict about their line endings in a way that feels petty until it costs an hour.

Probing without hanging or throwing

Everything above assumed the port was open. A scanner has to handle the other two outcomes, and both map straight onto states from the networking module. When connect reaches a closed port, the host's stack sends back an RST, and Python turns that into a ConnectionRefusedError. When connect reaches a filtered port, nothing comes back at all, the probe hits silence, and Python raises a timeout once the settimeout window expires. Closed is a fast exception. Filtered is a slow one.

Catching exceptions works for one port. Wrapping a try/except around every check in a loop over a thousand ports is noise. connect_ex removes the need. It runs the same handshake attempt but returns an integer instead of raising: 0 means the connection succeeded, and any non-zero value is the system error number for whatever went wrong. That single behavior is what keeps a scanning loop clean.

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.settimeout(1)
code = s.connect_ex(("10.10.10.1", 445))
if code == 0:
    print("445 open")
s.close()

Line up the return value with what happened on the wire and the mapping is exact. A return of 0 means the SYN-ACK came back and the handshake finished: the port is open. A quick non-zero return means an RST came back and the stack refused: the port is closed. A non-zero return that arrives only after the full timeout means nothing came back: the port is filtered, almost always by a firewall dropping the probe. The three port states from TCP, UDP, and Ports are now three Python outcomes, which is the entire foundation of the scanner in the next lesson.

The timeout is what makes filtered survivable. settimeout governs both connect and recv, so a small value caps how long the loop stalls on each silent port. A scanner uses something tight, around one second, because most of that second is spent waiting on nothing and a shorter wait sweeps more ports per minute. A single careful banner grab can afford three or five seconds. Set it too low and a slow but real service gets misread as filtered.

This connects one socket to one port and reads what comes back. Build a Port Scanner wraps that single check in a loop over a range of ports, hands the ports to a pool of threads so the timeouts overlap instead of stacking up one after another, and folds the banner grab back in so every open port also reports what is answering. The socket code does not change. Only the number of them running at once does.