📎 Coding Everybody 📎 Pororo님 블로그

1. Internet

1.1. IP & Domain

IP: 각 장치를 나타내는 IP 주소를 가리키는 말
Domain: 네트워크상에서 컴퓨터를 식별하는 호스트명

IP 기억하기 어렵기 때문에 Domain Name 사용
Domain name -> IP Address로 접속

DNS (Domain Name Server): 도메인별 IP 정보를 갖고 있는 서버
인터넷에 있는 Name Server에 접속해서 google.com의 IP를 알아낼 수 있음

1.2. Public & Private IP

public ip: ISP(Internet Service Provider)가 제공하는 인터넷 상에서의 컴퓨터의 주소
private ip: 어떠한 네트워크(Network) 안에서 사용되는 주소

컴퓨터 여러대 있는 가정의 경우, 공유기(Router)가 설치되어 있으면 IP 접속 실패
Router IP (public IP)에 연결되는 여러대 컴퓨터들(private IP)은 Port forwarding이 필요

1.3. Port

한 server의 port마다 다른 소프트웨어로 접속됨

예를들어 80번에 있는건 http (web server)
port list 확인

1.4. Port Forwarding

공유기 관리자 192.168.219.1(U+Net) 접속 (ipconfig해서 나오는 무선 LAN 어댑터 기본 게이트웨이)
고급설정 > NAT 설정 > Port Forwarding

80포트로 들어올 때, 80으로 포워딩 되게 내 IPv4 주소 넣고 설정

1.5. DHCP & DDNS

IP 고갈로 인해 IPv4(0.0.0.0 ~ 255.255.255.255) 더이상 사용하기 어려움
현재는 IPv4와 IPv6를 동시에 사용 중
오랫동안 사용하지 않으면 public IP를 회수하고 다시 사용시 새로운 IP로 재할당

동적 호스트 구성 프로토콜(Dynamic Host Configuration Protocol, DHCP): 장비에 고정적으로 IP를 부여하지 않고 컴퓨터를 사용할 때 남아 있는 IP 중에서 돌아가면서 부여하는 IP
동적 DNS (Dynamic Domain Name System, DDNS): 실시간으로 DNS를 갱신하는 방식으로 도메인과 호스트의 IP를 지속적을 일치화 시켜줌

2. HTTP

인터넷상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜

2.1. 구성

클라이언트

서버에 Request하는 클라이언트 소프트웨어(IE, Chrome, Firefox, Safari …)가 설치된 컴퓨터를 이용
클라이언트는 URI를 이용해서 서버에 접속하고, 데이터를 요청 가능

서버

클라이언트의 Request을 받아서, Request을 해석하고 Response을 하는 소프트웨어가 설치된 컴퓨터(Apache, nginx, IIS, lighttpd) 등이 서버 소프트웨어
표준포트: 80

2.2. 특징

Connectionless

서버에 연결하고, 요청해서 응답을 받으면 연결을 끊어버림

Stateless

연결을 끊어버리기 때문에, 클라이언트의 이전 상태를 알 수가 없음
cookie를 이용해서 이 문제를 해결

클라이언트와 서버의 상태 정보를 담고 있는 정보조각
e.g.) 로그인을 예로 들자면, 클라이언트가 로그인에 성공하면, 서버는 로그인 정보를 자신의 데이터베이스에 저장하고 동일한 값을 cookie형태로 클라이언트에 보냄

2.3. Request Header Format

GET /home.html HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/ *;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/testpage.html
Connection: keep-alive
Upgrade-Insecure-Requests: 1
If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT
If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"
Cache-Control: max-age=0
https://gmlwjd9405.github.io/2019/01/28/http-header-types.html

Request Line : 어떠한 방식(HTTP/1.1)으로, 어떠한 메소드(GET)를 통해 무엇을(/home.html) 요청했는지에 대한 메시지가 담겨있다.

1) Request Method : 요청 종류 명시

GET : 정보를 요청하기 위해서 사용한다. (SELECT)

POST : 정보를 밀어넣기 위해서 사용한다. (INSERT)

PUT : 정보를 업데이트하기 위해서 사용한다. (UPDATE)

DELETE : 정보를 삭제하기 위해서 사용한다. (DELETE)

HEAD : (HTTP)헤더 정보만 요청한다. 해당 자원이 존재하는지 혹은 서버에 문제가 없는지를 확인하기 위해서 사용한다.

OPTIONS : 웹서버가 지원하는 메서드의 종류를 요청한다.

TRACE : 클라이언트의 요청을 그대로 반환한다. 예컨데 echo 서비스로 서버 상태를 확인하기 위한 목적으로 주로 사용한다.

2) Request URI(Uniform Resource Identifiers) : 요청하는 자원의 위치를 명시
HTTP는 전송 프로토콜이고, URI는 자원의 위치를 알려주기 위한 프로토콜

e.g.)
https://nueees.github.io/techblog/network/2015/04/15/internet.html https : 자원에 접근하기 위해서 https 프로토콜을 사용
nueees.github.io : 자원의 인터넷 상에서의 위치 (도메인은 ip 주소로 변환되므로, ip 주소로 서버의 위치를 찾음)
techblog/network/2015/04/15/ 서버상 경로
internet.html : 요청할 자원의 이름

3) 프로토콜 방식과 버전 : 웹 브라우저가 사용하는 프로토콜 버전 명시 ( HTTP/1.1 )

Host 요청하는 호스트에 대한 호스트명 및 포트번호 (필수) HTTP/1.1 이후부터 Host 필드는 필수 항목이다. (웹브라우저는 이를 반드시 포함해야 함) Host 필드에 도메인명 및 호스트명 모두를 포함한 전체 URI(FQDN) 지정이 필요하다. 이에 따라 동일 IP 주소를 갖는 단일 서버에 여러 사이트를 구축할 수 있다.
User-Agent 클라이언트 소프트웨어(브라우저, OS) 명칭 및 버전 정보
Cookie 서버에 의해 Set-Cookie로 클라이언트에게 설정된 쿠키 정보 (쿠키/캐시 관련)
Referer 바로 직전에 머물었던 웹 링크 주소
Cache-Control: 캐쉬 제어 방식
max-age= : 캐시의 유효기간을 명시합니다.
max-stale[=] : 만료된 캐시를 응답으로 받아들일지 지정합니다. optional하게 응답이 만료되어서는 안되는 시간을 지정할 수 있습니다.
min-fresh= : 클라이언트가 지정 된 시간동안 신선한(문제가 없는) 상태로 유지 될 응답을 원함을 나타냅니다.
no-cache : 캐시를 사용하기 전에 재검증합니다.(서버로 요청을 보냄)
no-store : 아무것도 캐시하지 않습니다.
no-transform : 응답에 대해 변형이나 변환을 허용하지 않습니다.
only-if-cached : 무조건 캐시를 사용합니다.
response context
must-revalidate : 캐시를 사용하기전에 만료 상태를 확인하며, 만료된 것은 절대 사용하지 않습니다.
no-cache : 캐시를 사용하기 전에 재검증합니다.(서버로 요청을 보냄)
no-store : 아무것도 캐시하지 않습니다.
no-transform : 응답에 대해 변형이나 변환을 허용하지 않습니다.
public : 응답이 어떤 캐시에 의해서든 캐시된다는 것을 나타냅니다.
private : 응답이 단일 사용자를 위한것이며 공유 캐시에 의해 저장되지 않아야 한다는 것을 나타냅니다.
proxy-revalidate :must-revalidate와 동일하지만, 공유 캐시에만 적용됩니다.
max-age= : 캐시의 유효기간을 명시합니다.
s-maxage= : max-age 혹은 Expires 헤더를 재정의하나, 프록시 같은 공유 캐시에만 적용되며 사설 캐시에 의해서는 무시됩니다.
If-Modified-Since 제시한 일시 이후로만 변경된 리소스를 취득 요청
Authorization 인증 토큰(JWT/Bearer 토큰)을 서버로 보낼 때 사용하는 헤더 “토큰의 종류(Basic, Bearer 등) + 실제 토큰 문자”를 전송
Origin 서버로 POST 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지 나타낸다. 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생한다. 응답 헤더의 Access-Control-Allow-Origin와 관련
다음 4개는 주로 HTTP 메세지 Body의 속성 또는 내용 협상용 항목들

1) Accept 클라이언트 자신이 원하는 미디어 타입 및 우선순위를 알린다. 텍스트(text/html,text/plain,…),이미지(image/jpeg,…) 등 Ex) Accept: / 어떤 미디어 타입도 가능하다. Ex) Accept: image/* 모든 이미지 유형이 가능하다.

2) Accept-Charset 클라이언트 자신이 원하는 문자 집합

3) Accept-Encoding 클라이언트 자신이 원하는 문자 인코딩 방식

4) Accept-Language 클라이언트 자신이 원하는 가능한 언어 각각이 HTTP Entity Header 항목 중에 Content-Type, Content-Type charset-xxx, Content-Encoding, Content-Language과 일대일로 대응된다.

2.4. Response Headers Format

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Mon, 18 Jul 2016 16:06:00 GMT
Etag: "c561c68d0ba92bbeb8b0f612a9199f722e3a621a"
Keep-Alive: timeout=5, max=997
Last-Modified: Mon, 18 Jul 2016 02:36:04 GMT
Server: Apache
Set-Cookie: mykey=myvalue; expires=Mon, 17-Jul-2017 16:06:00 GMT; Max-Age=31449600; Path=/; secure
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
X-Backend-Server: developer2.webapp.scl3.mozilla.com
X-Cache-Info: not cacheable; meta data too large
X-kuma-revision: 1085259
x-frame-options: DENY
https://gmlwjd9405.github.io/2019/01/28/http-header-types.html

응답헤더에는 다양한 정보를 추가 가능

Request Line : 프로토콜과 응답코드 ( HTTP/1.1 200 OK )
Connection : 전송이 완료된 후 연결을 유지할지 말지 나타냅니다. HTTP/1.1의 경우 keep-alive가 default
Last-Modified: 컨텐츠의 마지막 수정일
Content-Length: 응답 메시지의 본문 크기를 바이트 단위
Keep-Alive: Keep Alive기능 설정 (timeout=5, max=997)
Server: 서버 소프트웨어 정보(Apache)
Set-Cookie: 서버측에서 클라이언트에게 세션 쿠키 정보를 설정 (RFC 2965에서 규정) (쿠키/캐시 관련)
Expires: 리소스가 지정된 일시까지 캐시로써 유효함을 나타낸다. 즉, 응답 컨텐츠가 언제 만료되는지를 나타낸다.
Ex) Expires: Thu, 26 Jul 2018 07:28:00 GMT
Cache-Control과 별개로 응답에 Expires라는 헤더를 줄 수 있다.
단, Cache-Control의 max-age가 있는 경우 이 헤더는 무시 (쿠키/캐시 관련)
Age: 캐시 응답. max-age 시간 내에서 얼마나 흘렀는지 초 단위로 알려준다. (쿠키/캐시 관련)
ETag: HTTP 컨텐츠가 바뀌었는지를 검사할 수 있는 태그 (쿠키/캐시 관련)
Proxy-authenticate
Allow:
해당 엔터티에 대해 서버 측에서 지원 가능한 HTTP 메소드의 리스트를 나타낸다.
때론, HTTP 요청 메세지의 HTTP 메소드 OPTIONS에 대한 응답용 항목으로 사용된다.
OPTIONS: 웹서버측 제공 HTTP 메소드에 대한 질의
Ex) Allow: GET,HEAD
405 Method Not Allowed 에러와 함께 웹 서버에서 제공 가능한 HTTP 메서드는 GET, HEAD 뿐임을 알린다.
Access-Control-Allow-Origin:
요청을 보내는 프론트 주소와 받는 백엔드 주소가 다르면 CORS 에러가 발생
서버에서 이 헤더에 프론트 주소를 적어주어야 에러가 나지 않는다.
Ex) Access-Control-Allow-Origin: www.zerocho.com
프로토콜, 서브도메인, 도메인, 포트 중 하나만 달라도 CORS 에러가 난다.
Ex) Access-Control-Allow-Origin: *
만약 주소를 일일이 지정하기 싫다면 *으로 모든 주소에 CORS 요청을 허용되지만 그만큼 보안이 취약해진다.
유사한 헤더로 Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 있다.
Request와 Allow에서 Method 단수 복수 주의

2.5. Response Code

https://developers.naver.com/docs/common/openapiguide/errorcode.md#%EC%A3%BC%EC%9A%94-%EC%98%A4%EB%A5%98-%EC%BD%94%EB%93%9C

1xx(정보) : 요청을 받았으며 프로세스를 계속 진행
2xx(성공) : 요청을 성공적으로 받았으며 인식했고 수용
3xx(리다이렉션) : 요청 완료를 위해 추가 작업 조치가 필요
4xx(클라이언트 오류) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없음
5xx(서버 오류) : 서버가 명백히 유효한 요청에 대한 충족을 실패

1XX : Information responses

상태 코드가 ‘1’로 시작하는 경우는 서버가 요청을 받았으며, 서버에 연결된 클라이언트는 작업을 계속 진행하라는 의미입니다. 해당 코드는 HTTP 1.0에서 지원되지 않습니다.

100 Continue

진행 중임을 의미하는 응답코드입니다. 현재까지의 진행상태에 문제가 없으며, 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 되는 것을 알려줍니다.

101 Switching Protocol

101은 클라이언트에 의해 보낸 업그레이드 요청 헤더에 대한 응답으로 보내집니다.

이 응답 코드는 클라이언트가 보낸 Upgrade 요청 헤더에 대한 응답에 들어가며, 서버에서 프로토콜을 변경할 것임을 알려줍니다. 해당 코드는 Websocket 프로토콜 전환 시에 사용됩니다.

102 Processing(WebDAV)

이 응답 코드는 서버가 요청을 수신하였으며 이를 처리하고 있지만, 아직 제대로 된 응답을 알려줄 수 없음을 알려줍니다.

2XX : Successful responses

200 OK

요청이 성공적으로 되었습니다. 정보는 요청에 따른 응답으로 반환됩니다.

201 Created

요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었습니다. 이 응답은 일반적으로 POST 요청 또는 일부 PUT 요청 이후에 따라옵니다.

202 Accepted

요청을 수신하였지만, 그에 응하여 행동할 수 없습니다. 이 응답은 요청 처리에 대한 결과를 이후에 HTTP로 비동기 응답을 보내는 것에 대해서 명확하게 명시하지 않습니다. 이것은 다른 프로세스에서 처리 또는 서버가 요청을 다루고 있거나 배치 프로세스를 하고 있는 경우를 위해 만들어졌습니다.

203 Non-Authoritative Information

이 응답 코드는 돌려받은 메타 정보 세트가 오리진 서버의 것과 일치하지 않지만 로컬이나 서드 파티 복사본에서 모아졌음을 의미합니다. 이러한 조건에서는 이 응답이 아니라 200 OK 응답을 반드시 우선됩니다.

204 No Content

요청에 대해서 보내줄 수 있는 콘텐츠가 없지만, 헤더는 의미있을 수 있습니다. 사용자-에이전트는 리소스가 캐시된 헤더를 새로운 것으로 업데이트 할 수 있습니다.

205 Reset Content

이 응답 코드는 요청을 완수한 이후에 사용자 에이전트에게 이 요청을 보낸 문서 뷰를 리셋하라고 알려줍니다.

206 Partial Content

이 응답 코드는 클라이언트에서 복수의 스트림을 분할 다운로드를 하고자 범위 헤더를 전송했기 때문에 사용됩니다. 클라이언트가 이어받기를 시도하면 웹서버가 이에 대한 응답코드로 ‘206 Partial Content’와 함께 Range 헤더에 명시된 데이터의 부분(byte)부터 전송을 시작합니다.

207 Multi-Status

멀티-상태 응답은 여러 리소스가 여러 상태 코드인 상황이 적절한 경우에 해당되는 정보를 전달합니다. 해당 코드는 WebDAV(Web Distributed Authoring and Vesioning)에 사용됩니다.

208 Already Reported

Prostat(property와 status의 합성어) 응답 속성으로 동일 컬렉션으로 바인드된 복수의 내부 멤버를 반복적으로 열거하는 것을 피하기 위해 사용됩니다. 해당 코드는 WebDAV(Web Distributed Authoring and Vesioning)에 사용됩니다.

226 IM Used ( HTTP Delta encoding )

서버가 GET 요청에 대한 리소스의 의무를 다 했고, 그리고 응답이 하나 또는 그 이상의 인스턴스 조작이 현재 인스턴스에 적용이 되었음을 알려줍니다.

3XX : Redirection messages

300 Multiple Choice

요청에 대해서 하나 이상의 응답이 가능합니다. 사용자 에언트 또는 사용자는 그중에 하나를 반드시 선택해야 합니다. 응답 중 하나를 선택하는 방법에 대한 표준화 된 방법은 존재하지 않습니다.

301 Moved Permanently

이 응답 코드는 요청한 리소스의 URI가 변경되었음을 의미합니다. 새로운 URI가 응답에서 아마도 주어질 수 있습니다.

302 Found

이 응답 코드는 요청한 리소스의 URI가 일시적으로 변경되었음을 의미합니다. 새롭게 변경된 URI는 나중에 만들어질 수 있습니다. 그러므로, 클라이언트는 향후의 요청도 반드시 동일한 URI로 해야합니다.

303 See Other

클라이언트가 요청한 리소스를 다른 URI에서 GET 요청을 통해 얻어야 할 때, 서버가 클라이언트로 직접 보내는 응답입니다.

304 Not Modified

이것은 캐시를 목적으로 사용됩니다. 이것은 클라이언트에게 응답이 수정되지 않았음을 알려주며, 그러므로 클라이언트는 계속해서 응답의 캐시된 버전을 사용할 수 있습니다.

305 Use Proxy

이전 버전의 HTTP 기술 사양에서 정의되었으며, 요청한 응답은 반드시 프록시를 통해서 접속해야 하는 것을 알려줍니다. 이것은 프록시의 in-band설정에 대한 보안상의 걱정으로 인하여 사라져가고 있습니다.

306 Unused

이 응답 코드는 더이상 사용되지 않으며, 현재는 추후 사용을 위해 예약되어 있습니다. 이것은 HTTP 1.1 기술사양 이전 버전에서 사용되었습니다.

307 Temporary Redirect

클라이언트가 요청한 리소스가 다른 URI에 있으며, 이전 요청과 동일한 메소드를 사용하여 요청해야 할 때, 서버가 클라이언트에 이 응답을 직접 보냅니다. 이것은 302 Found HTTP 응답 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 사용된 HTTP 메소드를 변경하지 말아야 하는 점만 다릅니다. 만약 첫 요청에 POST가 사용되었다면, 두번째 요청도 반드시 POST를 사용해야 합니다.

308 Permanent Redirect

이것은 리소스가 이제 HTTP 응답 헤더의 Location:에 명시된 영구히 다른 URI에 위치하고 있음을 의미합니다. 이것은 301 Moved Permanently HTTP 응답 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 HTTP 메소드를 변경하지 말아야 하는 점만 다릅니다. 만약 첫 요청에 POST가 사용되었다면, 두번째 요청도 반드시 POST를 사용해야 합니다.

4XX : Client error responses

400 Bad Request

이 응답은 잘못된 문법으로 인하여 서버가 요청하여 이해할 수 없음을 의미합니다.

401 Unauthorized

비록 HTTP 표준에서는 ‘미승인(unauthorized)’를 명확히 하고 있지만, 의미상 이 응답은 ‘비인증(unauthenticated)’를 의미합니다. 클라이언트는 요청한 응답을 받기 위해서는 반드시 스스로를 인증해야 합니다.

402 Payment Required

이 응답 코드는 나중에 사용될 것을 대비해 예약되었습니다. 첫 목표로는 디지털 결제 시스템에 사용하기 위하여 만들어졌지만 지금 사용되고 있지는 않습니다.

403 Forbidden

클라이언트는 콘텐츠에 접근할 권리를 가지고 있지 않습니다. 예를 들어, 그들은 미승인이어서 서버는 거절을 위한 적절한 응답을 보냅니다. 401과 다른 점은 서버가 클라이언트가 누구인지 알고 있습니다.

404 Not Found

서버는 요청받은 리소스를 찾을 수 없습니다. 브라우저에서는 알려지지 않은 URL을 의미합니다. 이것은 API에서 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수 있습니다. 서버들은 인증받지 않은 클라이언트로부터 리소스를 숨기기 위하여 이 응답을 403 대신에 전송할 수도 있습니다. 이 응답 코드는 웹에서 반복적으로 발생하기 때문에 가장 유명할지도 모릅니다.

405 Method Not Allowed

요청한 메소드는 서버에서 알고 있지만, 제거되었고 사용할 수 없습니다. 예를 들어, 어떤 API에서 리소스를 삭제하는 것을 금지할 수 있습니다. 필수적인 메소드인 GET과 HEAD는 제거될 수 없으며, 이 에러 코드를 리턴할 수 없습니다.

406 Not Acceptable

이 응답은 서버가 서버 주도 콘텐츠 협상을 수행한 후, 사용자 에이전트에서 정해준 규격에 따른 어떠한 콘텐츠도 찾지 않았을 때, 웹서버가 보냅니다.

407 Proxy Authentication Required

이것은 401과 비슷하지만 프록시에 의해 완료된 인증이 필요합니다.

408 Request Timeout

이 응답은 요청을 한 지 시간이 오래된 연결에 일부 서버가 전송하며, 어떤 때에는 이전에 클라이언트로부터 어떠한 요청이 없었다고 하더라도 보내지기도 합니다. 이것은 서버가 사용되지 않는 연결을 끊고 싶어하는 것을 의미합니다. 이 응답은 특정 몇몇 브라우저에서 빈번하게 보이는데 Chrome, Firefox 27+, 또는 IE 9와 같은 웹서핑 속도를 올리기 위해 HTTP 사전 연결 메카니즘을 사용하는 브라우저들이 해당됩니다. 또한 일부 서버는 이 메시지를 보내지 않고 연결을 끊어버리기도 합니다.

409 Conflict

이 응답은 요청이 현재 서버의 상태와 충돌될 때 보냅니다.

410 Gone

이 응답은 요청한 콘텐츠가 서버에서 영구적으로 삭제되었으며, 전달해 줄 수 있는 주소 역시 존재하지 않을 때 보냅니다. 클라이언트가 그들의 캐시와 리소스에 대한 링크를 지우기를 기대합니다. HTTP 기술 사양은 이 상태 코드가 ‘일시적인, 홍보용 서비스’에 사용되기를 기대합니다. API는 알려진 리소스가 이 상태 코드와 함께 삭제되었다고 강요해서는 안된다.

411 Length Required

서버에서 필요로 하는 Content-Length 헤더 필드가 정의되지 않은 요청이 들어왔기 때문에 서버가 요청을 거절합니다.

412 Precondition Failed

클라이언트의 헤더에 있는 전제조건은 서버의 전제조건에 적절하지 않습니다.

413 Payload Too Large

요청 엔티티는 서버에서 정의한 한계보다 큽니다. 서버는 연결을 끊거나 혹은 Retry-After 헤더 필드로 돌려보낼 것이다.

414 URI Too Long

클라이언트가 요청한 URI는 서버에서 처리하지 않기로 한 길이보다 깁니다.

415 Unsupported Media Type

요청한 미디어 포맷은 서버에서 지원하지 않습니다. 서버는 해당 요청을 거절할 것입니다.

416 Requested Range Not Satisfiable

Range 헤더 필드에 요청한 지정 범위를 만족시킬 수 없습니다. 범위가 타겟 URI 데이터의 크기를 벗어났을 가능성이 있습니다.

417 Expectation Failed

이 응답 코드는 Expect 요청 헤더 필드로 요청한 예상이 서버에서는 적당하지 않음을 알려줍니다.

418 I’m a teapot

서버는 커피를 찻 주전자에 끓이는 것을 거절합니다.

421 Misdirected Request

서버로 유도된 요청은 응답을 생성할 수 없습니다. 이것은 서버에서 요청 URI와 연결된 스킴과 권한을 구성하여 응답을 생성할 수 없을 때 보내집니다.

422 Unprocessable Entity (WebDAV)

요청은 잘 만들어졌지만, 문법 오류로 인하여 따를 수 없습니다.

423 Locked (WebDAV)

리소스는 접근하는 것이 잠겨있습니다.

424 Failed Dependency (WebDAV)

이전 요청이 실패하였기 때문에 지금의 요청도 실패하였습니다.

426 Upgrade Required

서버는 지금의 프로토콜을 사용하여 요청을 처리하는 것을 거절하였지만, 클라이언트가 다른 프로토콜로 업그레이드를 하면 처리를 할지도 모릅니다. 서버는 Upgrade 헤더와 필요로 하는 프로토콜을 알려주기 위해 426 응답에 보냅니다.

428 Precondition Required

오리진 서버는 요청이 조건적이어야 합니다. 클라이언트가 리소스를 GET해서, 수정하고, 그리고 PUT으로 서버에 돌려놓는 동안 서드파티가 서버의 상태를 수정하여 발생하는 충돌인 ‘업데이트 상실’을 예방하기 위한 목적입니다.

429 Too Many Requests

사용자가 지정된 시간에 너무 많은 요청을 보냈습니다(“rate limiting”).

431 Request Header Fields Too Large

요청한 헤더 필드가 너무 크기 때문에 서버는 요청을 처리하지 않을 것입니다. 요청은 크기를 줄인 다음에 다시 전송해야 합니다.

451 Unavailable For Legal Reasons

사용자가 요청한 것은 정부에 의해 검열된 웹페이지와 같은 불법적인 리소스입니다.

5XX : Server error reponses

500 Internal Server Error

웹 사이트 서버에 문제가 있음을 의미하지만 서버는 정확한 문제에 대해 더 구체적으로 설명할 수 없습니다.

501 Not Implemented

서버가 요청을 이행하는 데 필요한 기능을 지원하지 않음을 나타냅니다.

502 Bad Gateway

서버가 게이트웨이로부터 잘못된 응답을 수신했음을 의미합니다. 인터넷상의 서버가 다른 서버로부터 유효하지 않은 응답을 받은 경우 발생합니다.

503 Service Unavailable

서버가 요청을 처리할 준비가 되지 않았습니다. 일반적인 원인은 유지보수를 위해 작동이 중단되거나 과부하가 걸린 서버입니다. 이 응답과 함께 문제를 설명하는 사용자 친화적인 페이지가 전송되어야 한다는 점에 유의하십시오. 이 응답은 임시 조건에 사용되어야 하며, Retry-After: HTTP 헤더는 가능하면 서비스를 복구하기 전 예상 시간을 포함해야 합니다. 웹마스터는 또한 이러한 일시적인 조건 응답을 캐시하지 않아야 하므로 이 응답과 함께 전송되는 캐싱 관련 헤더에 대해서도 주의해야 합니다.

504 Gateway Timeout

웹페이지를 로드하거나 브라우저에서 다른 요청을 채우려는 동안 한 서버가 액세스하고 있는 다른 서버에서 적시에 응답을 받지 못했음을 의미합니다. 이 오류 응답은 서버가 게이트웨이 역할을 하고 있으며 적시에 응답을 받을 수 없을 경우 주어집니다. 이 오류는 대게 인터넷상의 서버 간의 네트워크 오류이거나 실제 서버의 문제입니다. 컴퓨터, 장치 또는 인터넷 연결에 문제가 아닐 수 있습니다.

505 HTTP Version Not Supported

서버에서 지원되지 않는 HTTP 버전을 클라이언트가 요청하였습니다. 대부분의 웹 브라우저는 웹 서버가 1.x 버전의 HTTP 프로토콜을 지원한다고 가정합니다. 실제로 1.0 이하의 매우 오래된 버전은 요즘 거의 사용되지 않습니다. 특히 최신 버전의 프로토콜보다 보안 및 성능이 좋지 않기 때문입니다. 따라서 웹 브라우저에서 이 오류가 표시되는 경우 웹 서버 소프트웨어에서 지원하는 HTTP 버전을 확인해 보아야 합니다.

506 Variant Also Negotiates

서버에 내부 구성 오류가 있는 경우 발생합니다. 요청을 위한 투명한 콘텐츠 협상이 순환 참조로 이어집니다.

507 Insufficient Storage

선택한 가변 리소스는 투명한 서버에 내부 구성 요류가 있는 경우 발생합니다. 콘텐츠 협상에 참여하도록 구성되므로 협상 과정에서 적절한 끝점이 아닙니다.

508 Loop Detected (WebDAV)

서버가 요청을 처리하는 동안 무한 루프를 감지한 경우 발생합니다.

510 Not Extended

서버가 요청을 이행하려면 요청에 대한 추가 확장이 필요합니다.

511 Network Authentication Required

511 상태 코드는 클라이언트가 네트워크 액세스를 얻기 위해 인증할 필요가 있음을 나타냅니다.

2.6. Network Tap

네트워크 탭 도구 살펴보기

가장 먼저 눈에 띄는 빨간점🔴은 기록되고 있다는 뜻이며, 기록되는 동안 주고받는 모든 Network 요소를 보여준다. 클릭 시 기록을 멈출 수 있으며 오른쪽 🚫을 클릭하면 기록된 모든 요소를 지운다.

Filter와 Search🔍는 이름과 같이 필터링하고, 검색하는 기능이고 하단 참조

Preserve log: 페이지가 이동되어도 로그가 사라지지 않는다.

Disable cache: 브라우저의 캐시를 비활성화 한다.

No throttling: Fast 3G, Slow 3G, Offline 등 다양한 환경에서의 사용경험을 테스트할 수 있도록 해주는 도구이며, 바로 옆 More network conditions…에서 더 다양한 환경을 테스트할 수 있다.

Filter

Filter는 네트워크 소스를 타입별로 볼 수 있으며, 대체로 Fetch/XHR 이 주로 사용된다. 별도의 Filtering 방식을 사용할 수 있는데, 예를들어 HTTP Method 가 GET 인 인터페이스만 Filtering 해보고 싶다면 method:GET 이라고 입력하면 된다. method와 같이 Filter 텍스트 박스에 입력할 수 있는 keyword는 다음과 같다.

domain
has-response-header
is
larger-than
method
mime-type
scheme
set-cookie-name
set-cookie-value
set-cookie-domain
status-code

Network 소스

Waterfall은 request가 언제, 얼마만큼의 시간이 소요되며 도달하는지에 대한 정보를 나타내며, Waterfall을 클릭하면 더 자세한 사항을 볼 수 있다.

Queued at s : 개발자 도구를 켠 순간부터 큐에 적재되는데 까지 걸리는 시간
Started at s : 개발자 도구를 켠 순간부터 request를 보내는데 까지 걸리는 시간
Queueing : 구문을 분석한 시점에서 큐에 적재되어 있는 시간
Stalled : 큐에서 request를 보내는 동안 정지되어 있는 시간
Proxy negotiation : 브라우저가 프록시 서버로 요청을 보내는데까지 걸리는 시간
Request sent : request를 보내는데 걸리는 시간
Waiting (TTFB) : response의 첫번째 바이트가 도달하는데까지 걸리는 시간 (TTFB: Time To First Byte)
Content Download : content가 다운로드가 되는데 까지 기다린 시간
Explanation : 총 소요되는 시간

Network 탭 최하단

DOMContentLoaded : Waterfall에서 파란색 선으로 표시가 되는 부분으로, DOM Tree를 그리는데 걸리는 시간을 나타낸다.
Load : Waterfall에서 빨간색 선으로 표시가 되는 부분으로, DOM Tree 구조를 포함하여, 이미지까지 화면에 로드되는 시간을 의미한다.
DOMContentLoaded와 Load는 사용자 경험을 판단하는 기준 중, 가장 기본이 되는 곳으로 프론트엔드 개발자에게 중요한 지표이다.

3. Switch

스위치는 자신에게 연결된 모든 기기들로 부터 들어오는 패킷을 수신하고, 이 패킷을 적당한 기기로 보내는 일

스위치를 이해하기 위해 기본적으로 OSI 7 Layer에서 사용하는 개념들이 필요

위 그림에서 2 Layer를 다룬다면 L2 스위치, 4 Layer는 L4 스위치, 7 Layer는 L7 스위치

3.1. L2 Switch

OSI Layer 2(Data Link)에 속하는 MAC Address 를 참조하여 Switching 하는 장비
스위치는 MAC table을 가지고 있어서 이것을 기준으로 packet을 해당 포트로 전달
하지만 라우팅이 불가능 하며, 상위 레이어 프로토콜을 이용한 스위칭이 불가능

3.2. L3 Switch

OSI Layer 3(Network)에 속하는 IP Address를 참조하여 Switching 하는 장비
라우팅: IP Address를 보고 적절한 포트로 패킷을 Switching 하는 것

3.3. L4 Switch

OSI Layer 3~4(Transport)에 속하는 IP Address, TCP/UDP 포트 정보를 참조하여 패킷을 확인하고 세션을 관리하며, 로드밸런싱을 제공하는 스위치 장비
TCP/UDP 패킷 정보를 분석해서 해당 패킷이 사용하는 서비스 종류별로 처리(HTTP, FTP, SMTP…)
하나의 IP를 port 번호(L4주소) 별로 따로 따로 분배하여 보낼수 있음

Internet -> L4 Switch -> http://www.naver.com 패킷(TCP/80)은 1번 서버
Internet -> L4 Switch -> https://www.naver.com 패킷(TCP/443)은 2번 서버
Internet -> L4 Switch -> ftp www.naver.com 패킷(TCP/20,21)은 3번 서버

세션관리, 서버/방화벽 로드밸런싱(Server IP를 Virtual IP와 매핑한 Table를 통해 여러 서버로 분산), 네트워크 서비스 품질 보장(failover)

L4 스위치의 문제점 : 서비스 단위 로드밸런싱 어렵고, 사용자의 IP가 수시로 변경되는 경우 해당 사용자에 대한 연속적인 서비스를 제공하기 어려움

3.4. L7 Switch

OSI Layer 3~7(Session, Presentation, Application)에 속하는 IP Address, 모든 TCP/UDP 포트(0-65535) 및 Packet 내용까지 참조하여 Switching 하는 장비
L4가 갖고 있는 문제점들을 해결, 패킷의 IP와 포트 정보 뿐만 아니라 패킷의 URL 정보, 쿠키, 플레이로드 정보등을 종합적으로 검사하여 사용자별로 연속적이고 차별하된 서비스를 제공

Internet -> L7 Switch -> www.naver.com/blog 는 1번 서버
Internet -> L7 Switch -> www.naver.com/cafe 는 2번 서버
Internet -> L7 Switch -> www.naver.com/book 는 3번 서버

기존 패킷 분석시 지원하지 않던 DDOS/SYN 공격 방어, CodeRed/Nimda 등 감염 패킷 필터링, 네트워크 자원 독점 방지 지원
URL별로 switching, session 분리(payload¹ 고려), HTTP header값으로 Traffic filter

데이터를 전송할 때, 헤더와 메타데이터, 에러 체크 비트 등과 같은 다양한 요소들을 함께 보내어, 데이터 전송의 효율과 안정성을 높히는데, 보내고자 하는 데이터 자체를 의미하는 것 ↩