timeout 2x as long as parameter

It seems that when I set a `timeout`, the exception is raised after `2 * timeout` seconds.

## Expected Result

log message shows up after `timout` seconds.

## Actual Result

```
2020-05-09 21:53:10,148 DEBUG: before get
2020-05-09 21:53:30,167 ERROR: timeout
```

## Reproduction Steps

```python
import requests

logger.debug("before get")
try:
    resp = requests.get(some_url, headers=some_headers, timeout=10)
except requests.Timeout:
    logger.error("timeout")
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.9"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.7.7"
  },
  "platform": {
    "release": "19.4.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.23.0"
  },
  "system_ssl": {
    "version": "1010107f"
  },
  "urllib3": {
    "version": "1.25.9"
  },
  "using_pyopenssl": false
}
```

Search past issues. Timeout is not a wall clock timeout. It could be that it took 9.9s for the connection to be made and another 10+s for the read to timeout. Also timeouts are never exact to the nanosecond in any programming language ever.

i had a quick look at past issues before posting but nothing jumped out at me.  do you have any links?

i also tried setting `timeout=(10, 0.1)` and the connection timeout still happened after 20s...  i'd find it strange to have a read timeout when there is no connection to read from...

i dont expect nanosecond precision.  but 10s and 20s is quite a difference.

You're catching `Timeout` as opposed to `ConnectTimeout` or `ReadTimeout`. That means this exception might not be due to a connection timeout as you seem to be assuming. The `ReadTimeout` doesn't timeout on time to first byte, but instead a timeout between bytes received. So if you're _actually_ getting a `ReadTimeout` then 0.1 may be just enough for you to continue to see this.

that is a valid point.  but it is a `ConnectTimeout`.  here is the full stack trace.  please note that the next log line shows up more or less after `20` seconds.  i guess that would make sense if urrlib3 retried at least another time, but AFAIK that is not the case without overriding it.

```
2020-05-10 14:21:36,986 DEBUG: before get
2020-05-10 14:21:57,016 ERROR: timeout
Traceback (most recent call last):
  File "/some_project/venv/lib/python3.7/site-packages/urllib3/connection.py", line 160, in _new_conn
    (self._dns_host, self.port), self.timeout, **extra_kw
  File "/some_project/venv/lib/python3.7/site-packages/urllib3/util/connection.py", line 84, in create_connection
    raise err
  File "/some_project/venv/lib/python3.7/site-packages/urllib3/util/connection.py", line 74, in create_connection
    sock.connect(sa)
socket.timeout: timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/some_project/venv/lib/python3.7/site-packages/urllib3/connectionpool.py", line 677, in urlopen
    chunked=chunked,
  File "/some_project/venv/lib/python3.7/site-packages/urllib3/connectionpool.py", line 381, in _make_request
    self._validate_conn(conn)
  File "/some_project/venv/lib/python3.7/site-packages/urllib3/connectionpool.py", line 976, in _validate_conn
    conn.connect()
  File "/some_project/venv/lib/python3.7/site-packages/urllib3/connection.py", line 308, in connect
    conn = self._new_conn()
  File "/some_project/venv/lib/python3.7/site-packages/urllib3/connection.py", line 167, in _new_conn
    % (self.host, self.timeout),
urllib3.exceptions.ConnectTimeoutError: (<urllib3.connection.HTTPSConnection object at 0x11043ef10>, 'Connection to some_url timed out. (connect timeout=10)')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/some_project/venv/lib/python3.7/site-packages/requests/adapters.py", line 449, in send
    timeout=timeout
  File "/some_project/venv/lib/python3.7/site-packages/urllib3/connectionpool.py", line 725, in urlopen
    method, url, error=e, _pool=self, _stacktrace=sys.exc_info()[2]
  File "/some_project/venv/lib/python3.7/site-packages/urllib3/util/retry.py", line 439, in increment
    raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='some_host', port=443): Max retries exceeded with url: /some_url (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x11043ef10>, 'Connection to some_url timed out. (connect timeout=10)'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/some_project/test.py", line ...
    timeout=10,
  File "/some_project/venv/lib/python3.7/site-packages/requests/api.py", line 76, in get
    return request('get', url, params=params, **kwargs)
  File "/some_project/venv/lib/python3.7/site-packages/requests/api.py", line 61, in request
    return session.request(method=method, url=url, **kwargs)
  File "/some_project/venv/lib/python3.7/site-packages/requests/sessions.py", line 530, in request
    resp = self.send(prep, **send_kwargs)
  File "/some_project/venv/lib/python3.7/site-packages/requests/sessions.py", line 643, in send
    r = adapter.send(request, **kwargs)
  File "/some_project/venv/lib/python3.7/site-packages/requests/adapters.py", line 504, in send
    raise ConnectTimeout(e, request=request)
requests.exceptions.ConnectTimeout: HTTPSConnectionPool(host='some_host', port=443): Max retries exceeded with url: some_url (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x11043ef10>, 'Connection to some_host timed out. (connect timeout=10)'))
```


in my understanding read timeouts are possible only after a successful connection is made. which is not the case.

So the other problem is likely that there are a lot of DNS entries that are slow/unresponsive and we try _all_ of them. I know I've also covered this in closed issues in the past. Since you're not sharing the URL, there's nothing else I can do to help you debug this. 

I guarantee if you tried this with a sane URL (e.g., httpbin.org) then you're likely find that things work as expected. (I say this because very little has changed in this project in the last 3 years, especially not the timeout work.)

ah, now this has pointed me in the correct direction, thanks.  the url is internal behind a VPN, so no point sharing it.  however it is a `CNAME` to a load balanced application with both ipv4 and ipv6 addresses.  so urllib3 is either trying the resolved `CNAME` again, or it's the ipv4/6 part.

now i need to find out how to stop cold after the first 10s and stop trying the other stuff...

thank you very much for the clue stick.  i guess this is a urllib3 issue and not requests. feel free to close.

> now i need to find out how to stop cold after the first 10s and stop trying the other stuff...

You want a wall clock timeout. That's not implementable in requests or urllib3. Please go read those issues.

> i guess this is a urllib3 issue and not requests. feel free to close

I am not a maintainer here. 

i think what i want is ipv4 only but thanks for the help! :D