HTTPS can run over any reliable stream transport protocol. Normally that's TCP, but it could also be SCTP. It is NOT expected to run over UDP, which is an unreliable datagram protocol (in fact, while that's not its official name, that's a good way to remember what it is).
The IANA assignment for UDP is historical; at the time, nearly every protocol was assigned both the TCP and UDP port numbers, even if it was expected that it would only ever use one. There has been discussion of merging the port number registries, and only ever assigning one port to one protocol from here on. That is to make it easier to deploy future transport protocols that would otherwise need their own registries. I'm not aware of how that discussion concluded.
TCP is backed by acks and retries to make sure you data gets where it's going. UDP is connectionless and "fire and forget". UDP is mostly used for streaming type applications, where if you lose some data you don't need to try to send it again.
Which one you use depends on the application. For example, a web server uses TCP.
Turn out my first answer to this question was correct at certain time, but it turned into another pitfall - to stay up to date please check Taxing rewrite pitfalls
I have been corrected by many SE users, so the credit goes to them, but more importantly, here is the correct code:
server {
listen 80;
server_name my.domain.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl;
server_name my.domain.com;
# add Strict-Transport-Security to prevent man in the middle attacks
add_header Strict-Transport-Security "max-age=31536000" always;
[....]
}
Best Answer
HTTPS can run over any reliable stream transport protocol. Normally that's TCP, but it could also be SCTP. It is NOT expected to run over UDP, which is an unreliable datagram protocol (in fact, while that's not its official name, that's a good way to remember what it is).
The IANA assignment for UDP is historical; at the time, nearly every protocol was assigned both the TCP and UDP port numbers, even if it was expected that it would only ever use one. There has been discussion of merging the port number registries, and only ever assigning one port to one protocol from here on. That is to make it easier to deploy future transport protocols that would otherwise need their own registries. I'm not aware of how that discussion concluded.