No, a TCP connection is uniquely identified by both source and destination IP and TCP (port) addresses. Changing any one of those will break the TCP connection (or prevent it from forming in the handshake).
What you may be referring to is the fact that a web browser will form, use, and close multiple TCP connections with the web server. Each connection will use a different browser TCP source port.
Edit, based on your comment:
RFC 793, Transmission Control Protocol defines TCP, and it explains:
Multiplexing:
To allow for many processes within a single Host to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. Concatenated with the network and
host addresses from the internet communication layer, this forms a
socket. A pair of sockets uniquely identifies each connection. That
is, a socket may be simultaneously used in multiple connections.
The binding of ports to processes is handled independently by each
Host. However, it proves useful to attach frequently used processes
(e.g., a "logger" or timesharing service) to fixed sockets which are
made known to the public. These services can then be accessed through
the known addresses. Establishing and learning the port addresses of
other processes may involve more dynamic mechanisms.
Connections:
The reliability and flow control mechanisms described above require
that TCPs initialize and maintain certain status information for each
data stream. The combination of this information, including sockets,
sequence numbers, and window sizes, is called a connection. Each
connection is uniquely specified by a pair of sockets identifying its
two sides.
When two processes wish to communicate, their TCP's must first
establish a connection (initialize the status information on each
side). When their communication is complete, the connection is
terminated or closed to free the resources for other uses.
Since connections must be established between unreliable hosts and
over the unreliable internet communication system, a handshake
mechanism with clock-based sequence numbers is used to avoid erroneous
initialization of connections.
TCP creates a bidirectional connection between process/application peers (much like ethernet creates a bidirectional connection between hosts), and the connection can be used by each side to both send and receive. TCP, itself, does not have clients or servers, that is an application-layer concept. The web browser will use the TCP connection to send requests to the web server, and the web server will use the same connection to send responses to the requests back to the web browser.
The web browser can send multiple requests and receive the replies to the requests on the same TCP connection. Some web browsers will set up multiple connections to the web server in order to request different web page elements at the same time, but that is an application-layer behavior, not a behavior of TCP, and application behaviors are off-topic here.
A server process usually listens on a well-known port number, e.g. TCP port 80 for HTTP. A client process will request TCP to create a connection to the server process at the server's well-known port number, and usually using the reserved port 0
so that TCP will assign the client process an ephemeral port number for that connection. When the TCP connection is terminated (either side can terminate the connection), the ephemeral port is returned to the pool of ephemeral port numbers to be reused for a different connection. Some OSes will use the ephemeral port numbers from the available pool in a specific order, and some will randomly choose an ephemeral port number for each connection.
The actual establishment of a connection is explained in the RFC:
2.7. Connection Establishment and Clearing
To identify the separate data streams that a TCP may handle, the TCP
provides a port identifier. Since port identifiers are selected
independently by each TCP they might not be unique. To provide for
unique addresses within each TCP, we concatenate an internet address
identifying the TCP with a port identifier to create a socket which
will be unique throughout all networks connected together.
A connection is fully specified by the pair of sockets at the ends. A
local socket may participate in many connections to different foreign
sockets. A connection can be used to carry data in both directions,
that is, it is "full duplex".
TCPs are free to associate ports with processes however they choose.
However, several basic concepts are necessary in any implementation.
There must be well-known sockets which the TCP associates only with
the "appropriate" processes by some means. We envision that processes
may "own" ports, and that processes can initiate connections only on
the ports they own. (Means for implementing ownership is a local
issue, but we envision a Request Port user command, or a method of
uniquely allocating a group of ports to a given process, e.g., by
associating the high order bits of a port name with a given process.)
A connection is specified in the OPEN call by the local port and
foreign socket arguments. In return, the TCP supplies a (short) local
connection name by which the user refers to the connection in
subsequent calls. There are several things that must be remembered
about a connection. To store this information we imagine that there is
a data structure called a Transmission Control Block (TCB). One
implementation strategy would have the local connection name be a
pointer to the TCB for this connection. The OPEN call also specifies
whether the connection establishment is to be actively pursued, or to
be passively waited for.
A passive OPEN request means that the process wants to accept incoming
connection requests rather than attempting to initiate a connection.
Often the process requesting a passive OPEN will accept a connection
request from any caller. In this case a foreign socket of all zeros is
used to denote an unspecified socket. Unspecified foreign sockets are
allowed only on passive OPENs.
A service process that wished to provide services for unknown other
processes would issue a passive OPEN request with an unspecified
foreign socket. Then a connection could be made with any process that
requested a connection to this local socket. It would help if this
local socket were known to be associated with this service.
Well-known sockets are a convenient mechanism for a priori associating
a socket address with a standard service. For instance, the
"Telnet-Server" process is permanently assigned to a particular
socket, and other sockets are reserved for File Transfer, Remote Job
Entry, Text Generator, Echoer, and Sink processes (the last three
being for test purposes). A socket address might be reserved for
access to a "Look-Up" service which would return the specific socket
at which a newly created service would be provided. The concept of a
well-known socket is part of the TCP specification, but the assignment
of sockets to services is outside this specification. (See [4].)
Processes can issue passive OPENs and wait for matching active OPENs
from other processes and be informed by the TCP when connections have
been established. Two processes which issue active OPENs to each
other at the same time will be correctly connected. This flexibility
is critical for the support of distributed computing in which
components act asynchronously with respect to each other.
There are two principal cases for matching the sockets in the local
passive OPENs and an foreign active OPENs. In the first case, the
local passive OPENs has fully specified the foreign socket. In this
case, the match must be exact. In the second case, the local passive
OPENs has left the foreign socket unspecified. In this case, any
foreign socket is acceptable as long as the local sockets match. Other
possibilities include partially restricted matches.
If there are several pending passive OPENs (recorded in TCBs) with the
same local socket, an foreign active OPEN will be matched to a TCB
with the specific foreign socket in the foreign active OPEN, if such a
TCB exists, before selecting a TCB with an unspecified foreign socket.
The procedures to establish connections utilize the synchronize (SYN)
control flag and involves an exchange of three messages. This exchange
has been termed a three-way hand shake [3].
A connection is initiated by the rendezvous of an arriving segment
containing a SYN and a waiting TCB entry each created by a user OPEN
command. The matching of local and foreign sockets determines when a
connection has been initiated. The connection becomes "established"
when sequence numbers have been synchronized in both directions.
The clearing of a connection also involves the exchange of segments,
in this case carrying the FIN control flag.