Why is SSL not under TCP (the Transport layer)?
why the SSL is not under the TCP ( Transport layer ) ?
Because SSL can use TCP  to transport SSL records, and so SSL relies on TCP as a service.
That is, SSL takes the user data stream, and converts it into a series of records; it then gives these records to TCP to transmit. On the other side, the receiver's TCP stack gets these records and gives it to SSL to decrypt.
Similarly, TCP takes the data it has been given, and converts it into a series of segments; it then gives these segments to IP to transmit (hence TCP is shown on top of IP).
 There's no requirement that SSL has to use TCP; it's just what is used in practice.
The Secure Socket Layer is as the name suggests build on sockets, which provide error free, ordered stream of data. TLS is the differently named successor to SSL; TLS 1.0 succeeds SSL 3. TLS likewise is named Transport Layer Security. TCP is the transmission control protocol that is build on top of IP to provide this transport layer.
TLS requires two reliable, error free, ordered streams of data to operate - it provides two secured streams in return. TLS works well on any reliable, ordered stream, not just TCP. It's just that TCP is the most common streaming protocol at the transport layer of the Internet. The internet protocol (IP) by itself doesn't provide this streaming capability; it only specifies how to route individual packets.
Note that SSL is used to protect the transport layer of many internet protocols. These protocols are handled by the various services on the internet. So having security at this level means that SSL provides application specific security; each port can be secured, sometimes even after the protocol has started (STARTTLS on mail connections, for instance).
There is also a version of TLS called DTLS which operates on UDP; UDP offers unordered data packets and DTLS can be used to secure those packets. And IPSEC has already been named which can be used to implement security at the internetworking / datagram level.
You are currently likely using the secure version of the cryptography site, which uses HTTPS, HTTP over SSL on a TCP socket connected to port number 443 on the application server (or by a proxy or SSL accelerator in front of it).
While the other answers are good, I think they're missing the core point: TCP is what's there. You can't just define arbitrary new layer-4 protocols on top of IP and expect existing operating systems and network equipment (especially: think NAT) to handle them. By doing SSL on top of TCP, you make it so it works anywhere TCP can work, and so that it's not blocked, intentionally or unintentionally, without some sort of deep packet inspection that violates standard network semantics.
It was an unfortunate design decision, because it built denial of service into the protocol with unauthenticated RST packets. But it was expedient because TCP is ubiquitous and deals with things like packet reordering congestion control.
Modern protocols like CurveCP, MinimaLT (paywall-free link, with reference), and QUIC sensibly operate at the packet layer and incorporate congestion control and cryptography to deal with the denial-of-service vector. Unfortunately, in the two decades since SSL was created, TCP has become still more ubiquitous and more and more middleboxes have gotten in the way of UDP-based protocols or custom IP protocols.
Realistically, if you replaced TCP with something like SSL you'd have to re-implement TCP in your new protocol anyway.
TCP handles packet order, service selection, data stream association, retransmission, error detection, flow and congestion control... you'd have to do all of that in your new protocol, otherwise it wouldn't be reliable. If you're already re-implementing most of the features and overhead of TCP you might as well use TCP and save yourself the hassle and security implications of repeating work.
Plus it automatically has some compatibility with anything that works on TCP already, and putting it over TCP means you can start a connection in clear and then switch to encrypted if both ends support it (see STARTTLS).
You can use the analogy of shipping to describe how SSL works. TCP would be a wagon that carries information. SSL will wrap that information in a locked safe before it gets put on the wagon. But without the wagon, it's not going anywhere.
But without a driver, the wagon can't be trusted to get where it's going. So the wagon is "IP", the driver is "TCP" and the locked safe is "SSL"
The "below TCP version of SSL" is IPSEC.
IPsec is an end-to-end security scheme operating in the Internet Layer of the Internet Protocol Suite, while some other Internet security systems in widespread use, such as Transport Layer Security (TLS) and Secure Shell (SSH), operate in the upper layers at the Transport Layer (TLS) and the Application layer (SSH). IPsec can automatically secure applications at the IP layer.