[Server] 체크사항 / 최적화

[hochan222]

우리의 목표는 100억.. Request 최적화를 해봐요.. 아이디어 투척..

• [ ] read/recv/write/send 의 리턴값을 반드시 체크. -1, 0, 그 이상인지 모두 체크해야함.
• [ ] select() 는 read set, write set 을 한번에 체크하고 select() 이후 클라이언트 소켓별로 단 한번의 read 또는 write 를 써야만 한다.
• [ ] 단일 연결에 여러개의 요청을 처리 여부
• [ ] siege -b 명령어로 서버 부하테스트에서 99.5% 를 넘겨야함. 해당 명령어를 수행하면 무한루프가 되는데 ctrl-c 를 할때까지 멈추지 않고 계속 무한히 돌아가야함.
• [x] config 잘못된 경로 입력시 segfault 방지

최적화

• [x] 참조자를 잘쓰자
  • 1.18
• [x] cgi 구조에 대하여
• heap 보다는 static이 좋다. header를 읽는데 너무 큰 buffer를 읽는건 별루다. 적당한 size로 읽자.
  • "Keep in mind your stack memory is a lot faster than your heap memory" That is actually incorrect. While stack allocations can be faster, there's nothing that makes stack memory inherently faster than heap memory, once space is allocated. The underlying access costs are the same. Heap memory could be fragmented though, which not only incurs an access penalty but kills cache locality and performance. In this case stack allocated memory will indeed be "a lot faster"
• console.log 를 다 지우자.

string에 대하여

• [x] result = result + s[i] => result += s[i];

• [x] result.reserve(s.length()) 미리 저장 공간을 예약하자.

• [x] s의 포인터 역참조 제거 => iterator 사용

• [x] iter.end() 값 캐싱하기.

• http://charlie0301.blogspot.com/2020/05/c-4.html

Headers

• [x] Accept-Charsets
• [x] Accept-Language
• [x] Allow
• [x] Authorization
• [x] Content-Language
• [x] Content-Length
• [x] Content-Location
• [x] Content-Type
• [x] Date
• [x] Host
• [x] Last-Modified
• [x] Location
• [x] Referer
• [x] Retry-After
• [x] Server
• [x] Transfer-Encoding
• [x] User-Agent
• [x] WWW-Authenticate

[hochan222]

• map 해제!!?! (다른 사람 코드에 있길래.. 적어봤습니댜)

  for ( std::map<long, Server>::iterator it = _servers.begin() ; it != _servers.end() ; it++ )
      it->second.clean();

[hochan222]

Content-Location

Content-Location 헤더는 반환된 데이터에 대한 대체 위치을 가르킵니다. 주된 유스케이스는 컨텐츠 협상의 결과로써 전달되는 리소스의 URL을 가르키는 것입니다.

Content-Location: /index.html

• https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Content-Location

---

Content-Location URI가 요청 된 URI와 다른 경우 표시된 URI의 캐시 항목이 무효화됩니다.( https://tools.ietf.org/html/rfc7234#section-4.4 및 https://tools.ietf.org/html/rfc2616#section-13.10 참조 )

Content-Location URI가 요청 된 URI와 같으면 PUT / POST 요청에 대한 응답이 동일한 위치에서 GET 요청에 대한 200 응답에 의해 수신되는 응답과 동일 함을 캐시에 표시합니다. 따라서 캐시 될 수 있습니다. ( https://tools.ietf.org/html/rfc7231#section-3.1.4.2 참조 ) Firefox 및 Chrome은이를 구현하지 않는 것으로 보입니다.

• Firefox 및 Chrome은이를 구현하지 않는 것으로 보입니다.
• 실제로 HTTP RFC는 PUT 및 POST에 대한 Content-Location의 정의 된 동작이 없다고 말합니다. –

https://stackoverflow.com/questions/447679/what-is-the-purpose-of-the-http-header-field-content-location

---

결론. 현재 브라우저에 구현돼있지 않음으로 허울뿐인 헤더라 할 수 있겠다.

[hochan222]

Host

• Host 헤더의 필드는 모든 HTTP/1.1 요청 메시지 내에 포함되어 전송되어야 합니다.
• Host 헤더 필드가 없거나 한 개 이상의 필드를 포함하는 HTTP/1.1 요청 메시지에 대해서는 400 (Bad Request) 상태 코드가 전송될 것입니다.

Host: <host>:<port>
Host: developer.mozilla.org

• https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Host

---

GET /imgs/favicon.jpg HTTP/1.1
Host: localhost:8080
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
Accept: image/avif,image/webp,image/apng,image/*,*/*;q=0.8
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: image
Referer: http://localhost:8080/
Accept-Encoding: gzip, deflate, br
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

[hochan222]

Retry-After

Retry-After 응답 HTTP 헤더는 다음에 올 요청이 이루어지기 전에 사용자 에이전트가 대기해야 하는 시간을 가르킵니다. 이 헤더가 사용되는 주요한 두 가지 경우가 있습니다:

• 503 (Service Unavailable) 응답이 전송된 경우, 서비스가 얼마나 오랫동안 이용 불가능한지 예측되는 시간을 가르킵니다.
• 301 (Moved Permanently)와 같은, 리다이렉트 응답이 전송된 경우, 리다이렉트 요청을 하기 이전에 사용자 에이전트가 대기해주길 원하는 최소한의 시간을 가르킵니다.

Retry-After: <http-date>
Retry-After: <delay-seconds>

\ 응답이 수신된 이후 지연시키기 위한 초를 가르키는 음수를 불허하는 10진수 정수값입니다.

Retry-After: Wed, 21 Oct 2015 07:28:00 GMT
Retry-After: 120

클라이언트와 서버 양측의 Retry-After 헤더 지원은 여전히 부조화스럽습니다. 하지만, Googlebot과 같은, 어떤 크롤러와 스파이더들은 Retry-After 헤더를 지킵니다. 검색 엔진이 다운타임이 경과한 경우 당신의 사이트에 대한 인덱싱을 유지할 것이기에, 503 (Service Unavailable) 응답에서 해당 헤더를 함께 보내는 것은 유용합니다.

• https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Retry-After

[hochan222]

Location

• Location응답 헤더에 페이지를 리디렉션 할 URL을 나타냅니다.
• 3xx (리디렉션) 또는 201(생성 된) 상태 응답과 함께 제공 될 때만 의미를 제공합니다.

Location: <url>

Location: /index.html

---

301

GET / HTTP/1.1
Host: localhost:8080
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
Accept: */*
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: script
Referer: http://localhost:8080/index.html
Accept-Encoding: gzip, deflate, br
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
If-Modified-Since: Fri, 26 Mar 2021 12:38:38 KST

HTTP/1.1 302 Found
content-language: ko, en
content-length: 0
content-type: text/html; charset=UTF-8
date: Fri, 26 Mar 2021 12:38:38 KST
last-modified: Fri, 26 Mar 2021 12:38:38 KST
location: /index.html
server: ftnix/1.0 (MacOS)
status: 302

GET /index.html HTTP/1.1
Host: localhost:8080
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
Accept: text/css,*/*;q=0.1
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: style
Referer: http://localhost:8080/index.html
Accept-Encoding: gzip, deflate, br
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
If-Modified-Since: Fri, 26 Mar 2021 12:38:38 KST

HTTP/1.1 200 OK
content-language: ko, en
content-length: 2265
content-type: text/html; charset=UTF-8
date: Fri, 26 Mar 2021 12:38:38 KST
last-modified: Fri, 26 Mar 2021 12:38:38 KST
location: /index.html
server: ftnix/1.0 (MacOS)
status: 200

<!DOCTYPE html>
... 생략

---

201

HTTP 201 Created는 요청이 성공적으로 처리되었으며, 자원이 생성되었음을 나타내는 성공 상태 응답 코드입니다. 해당 HTTP 요청에 대해 회신되기 이전에 정상적으로 생성된 자원은 회신 메시지의 본문(body)에 동봉되고, 구체적으로는 요청 메시지의 URL이나, Location (en-US) 헤더의 내용에 위치하게 됩니다.

원본 서버는 201 상태 코드를 반환하기 전에 리소스를 생성해야합니다 . 조치를 즉시 수행 할 수없는 경우 서버는 202 (Accepted)대신 응답으로 응답해야합니다.

• header: 생성된 path
• body: 보여줄 content

#참고

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location

[hochan222]

Referer

• Referer 요청 헤더는 현재 요청된 페이지의 링크 이전의 웹 페이지 주소를 포함합니다.

• Referer 헤더는 사람들이 어디로부터 와서 방문 중인지를 인식할 수 있도록 해주며 해당 데이터는 예를 들어, 분석, 로깅, 혹은 캐싱 최적화에 사용될 수도 있습니다.

• Referer 헤더는 다음과 같은 경우 브라우저에 의해 전송되지 않습니다:

  • 참조되는 리소스가 로컬 "파일" 혹은 "데이터"의 URI인 경우,
  • 안전하지 않은 HTTP 요청이 사용되고 참조 페이지가 보안 프로토콜(HTTPS)로 수신된 경우.

• 값은 request message에 들어오므로 받아쓰면 됨

Referer: <url>

Referer: https://developer.mozilla.org/en-US/docs/Web/JavaScript

• https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Referer

[hochan222]

User-Agent

서버는 추가하지 않음으로 패스

The User-Agent request header is a characteristic string that lets servers and network peers identify the application, operating system, vendor, and/or version of the requesting user agent.

User-Agent: <product> / <product-version> <comment>

User-Agent: Mozilla/5.0 (<system-information>) <platform> (<platform-details>) <extensions>

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent

[hochan222]

Transfer-Encoding

HTTP 1.1에서는 기본적으로 연결 유지 기능이 활성화 되어 있다. 하나의 TCP 커넥션에 여러개의 요청이 가능하기 때문에 클라이언트는 요청마다 전달될 컨텐츠의 데이터 사이즈를 미리 알고 있어야 한다. 웹서버가 전달해 주는 컨텐츠의 시작과 끝을 알아야만 해당 요청에 대한 처리가 올바르게 될 수 있기 때문이다.

Hop-by-hop headers

• 이러한 헤더는 단일 전송 수준 연결에만 의미가 있으며 프록시에 의해 재전송되거나 캐시 되지 않아야 합니다 . Connection일반 헤더를 사용하여 홉별 헤더 만 설정할 수 있습니다 .

Transfer-Encoding: chunked
Transfer-Encoding: compress
Transfer-Encoding: deflate
Transfer-Encoding: gzip
Transfer-Encoding: identity

// 어떤 값들은 쉼표로 구분하여 나열될 수 있습니다
Transfer-Encoding: gzip, chunked

---

chunked

데이터가 발송의 청크 내에서 전송됩니다. Content-Length헤더는이 경우 생략, 각 청크의 앞부분에 현재 청크의 길이가 16 진수 형태로오고 그 안에는 '\ r \ n'이오고 그 다음에 청크 자체가 오며, 그 안에는 다시 '\ r \ n'이 옵니다. 종료 청크는 그것의 길이가 0 인 것을 제외하면 일반적인 청크와 다르지 언어입니다. 그 다음에는 (비어 있을수도있는) 연속 된 수많은 필드가 있습니다.

• 데이터 스트리밍을위한 자체 메커니즘을 제공하는 HTTP / 2 에서는 청크 전송 인코딩이 지원되지 않습니다 .

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
\r\n

---

4\r\n (bytes to send)
Wiki\r\n (data)
6\r\n (bytes to send)
pedia \r\n (data)
E\r\n (bytes to send)
in \r\n
\r\n
chunks.\r\n (data)
0\r\n (final byte - 0)
\r\n (end message)

Wikipedia in

chunks.

#참고

• https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Transfer-Encoding
• https://en.wikipedia.org/wiki/Chunked_transfer_encoding
• https://withbundo.blogspot.com/2017/08/http-20-http-ii-transfer-encoding.html?m=1

[hochan222]

Allow

어떤 요청 메소드를 사용할 수 있는지 알리기 위해 서버가 405 Method Not Allowed 상태코드로 응답할 경우에 이 헤더를 반드시 보내야 합니다.