diff --git "a/2\354\243\274\354\260\250/kwYoohae/DNS_\354\232\224\354\262\255\352\263\274\354\240\225.md" "b/2\354\243\274\354\260\250/kwYoohae/DNS_\354\232\224\354\262\255\352\263\274\354\240\225.md" new file mode 100644 index 0000000..dc94686 --- /dev/null +++ "b/2\354\243\274\354\260\250/kwYoohae/DNS_\354\232\224\354\262\255\352\263\274\354\240\225.md" @@ -0,0 +1,8 @@ +## DNS 요청 과정 +1. 사용자가 Browser에 www.naver.com과 같은 도메인 이름을 입력해서 요청을 합니다. +2. 우선 DNS 캐시에 www.naver.com의 주소가 있는지 확인합니다 + - 캐시는 컴퓨터에도 있지만, 브라우저에도 존재합니다 `chrome://net-internals/#dns`로 확인이 가능합니다 +3. 만약 없으면 로컬 DNS서버에서도 DNS 쿼리를 보내서 확인을합니다. +4. 그럼에도 불구하고 없다면 이제 루트 DNS -> TLD DNS -> Domain Name Server순으로 반복 혹은 재귀적 쿼리를 보내서 IP 주소를 얻어옵니다 + - 도메인서버까지 가기전에 TLD나 Root등은 어떤 DNS 서버가 알고있다고 알려주는 역학을 수행합니다 +5. IP 주소는 DNS 캐시에 저장되고, 이를 사용해서 통신을 합니다 \ No newline at end of file diff --git "a/2\354\243\274\354\260\250/kwYoohae/HTTP2_Multiplexing.md" "b/2\354\243\274\354\260\250/kwYoohae/HTTP2_Multiplexing.md" new file mode 100644 index 0000000..8923cd3 --- /dev/null +++ "b/2\354\243\274\354\260\250/kwYoohae/HTTP2_Multiplexing.md" @@ -0,0 +1,17 @@ +## Multiplexing +- 기존 HTTP1.1에서는 한 번의 TCP 연결에 하나의 요청과 응답만 처리가 가능하였습니다 + - 그렇기 때문에 여러 리소스에 대해서 처리를 한다면, 리소스간 대기 시간이 생겨서 로딩시간이 길어졌습니다 +- 이를 해결하기 위해서 Multiplexing이라는 매커니즘이 동작되었고 아래는 해당 매커니즘을 구성하는 설명입니다 + +### Frame +- HTTP1.1에서는 Plain Text로 보내고 개행으로 메시지를 구별하였다 + - 하지만 HTTP2.0부터는 Binary로 인코딩된 Message, Frame이 생기게 되었습니다. + - HTTP2.0은 메시지를 Binary로 구성하고 더 작은 Frame으로 쪼개서 이를 관리합니다. +- 이떄, Frame은 HTTP/2의 최소 통신단위로 모든 패킷에는 하나의 Frame Header가 존재합니다 + - 헤더에 프레임에 대한 식별자, 우선순위등이 있어서 응답의 순서를 고려하지 않고 보내도 순서대로 정렬이 가능합니다 + - 이런 헤더는 HPACK알고리즘을 통해 압축해서 대역폭을 절약합니다. +### Stream +- HTTP/2는 Stream을 사용해서 데이터를 병렬로 전송을 합니다 +- 이는 여러개의 요청과 응답을 병렬로 처리하는 기본적인 단위로 볼 수 있습니다. + - 각 스트림은 순서를 가져서 중요한 리소스 부터 처리할 수 있습니다. +- HTTP/2는 이러한 스트림의 개수나 우선순위를 조절하면서 동시성을 해결하고 있습니다. \ No newline at end of file diff --git "a/2\354\243\274\354\260\250/kwYoohae/README.md" "b/2\354\243\274\354\260\250/kwYoohae/README.md" new file mode 100644 index 0000000..a734ec0 --- /dev/null +++ "b/2\354\243\274\354\260\250/kwYoohae/README.md" @@ -0,0 +1,15 @@ +### TODO +- [x] TCP/IP의 4계층 +- [X] DNS 주소를 찾을 때 어떤 과정을 거치는지 +- [X] 흐름제어 혼잡제어가 뭔지 +- [X] HTTP/2에서의 Multiplexing이 뭐지 + + +### 질문 사항 +- DNS 레코드가 뭔가요? +- HTTP의 각버전의 차이는? +- HTTP의 메서드의 특징 (멱등성) +- HTTP 상태코드에서 400과 500의 차이 +- HTTP에서 캐시를 적용하는 방법 +- 쿠키의 옵션에 대한 설명 +- 소켓의 동작방식 diff --git "a/2\354\243\274\354\260\250/kwYoohae/TCP_IP_4\352\263\204\354\270\265.md" "b/2\354\243\274\354\260\250/kwYoohae/TCP_IP_4\352\263\204\354\270\265.md" new file mode 100644 index 0000000..d30be40 --- /dev/null +++ "b/2\354\243\274\354\260\250/kwYoohae/TCP_IP_4\352\263\204\354\270\265.md" @@ -0,0 +1,16 @@ +## TCP/IP 4계층 +### 링크 계층 + - 링크 계층은 물리적인 네트워크 매체를 통한 신호 전송과 관련된 기능을 다룸 + - LAN 등에 사용이 됩니다 +### 네트워크 계층 +- 데이터의 Routing 및 Packet 전달을 다루는 계층입니다 +- IP주소를 통해서 식별을 해서 목적지까지 패킷을 전달하는 역할을 합니다 + - 순서가 없고, 패킷 전달 여부를 보증하지 않습니다. +### Transport 계층 +- 데이터의 전송을 관리하고, 두 컴퓨터간의 연결을 설정, 유지, 해제하는 역할을 담당합니다 +- TCP/UDP등이 이 계층에서 수행이됩니다 + - 순서를 보장하고 손실된 패킷에 대해서 재전송등을 합니다 +### Application 께층 +- 실제 사용자나 응용 프로그램이 상호 작용하는 계층이비낟 + - HTTP, SMTP, FTP과 같은 다양한 프로토콜이 사용이 됩니다. + diff --git "a/2\354\243\274\354\260\250/kwYoohae/\355\235\220\353\246\204\354\240\234\354\226\264_\355\230\274\354\236\241\354\240\234\354\226\264.md" "b/2\354\243\274\354\260\250/kwYoohae/\355\235\220\353\246\204\354\240\234\354\226\264_\355\230\274\354\236\241\354\240\234\354\226\264.md" new file mode 100644 index 0000000..9a096ee --- /dev/null +++ "b/2\354\243\274\354\260\250/kwYoohae/\355\235\220\353\246\204\354\240\234\354\226\264_\355\230\274\354\236\241\354\240\234\354\226\264.md" @@ -0,0 +1,25 @@ +## 흐름제어 +- 만약, 송신측이 데이터를 수신측이 처리를 못하면 늦어지게된다 (데이터의 양) + - 만약, 늦어지면 패킷이 손실 될 수도 있다 + - 이를 해결하기 위해 흐름제어를 사용해서 송신측과 수신측의 네트워크 데이터 처리 속도차이를 해결한다 +- TCP에서는 흐름제어에는 여러가지 방식이 있다 +### Stop And Wait +- TCP는 전송을 할 떄, 매번 전송한 패킷에 대해 ACK응답을 받아야만 그 다음 패킷을 전송하는 흐름제어 해결방법입니다 +### Sliding Window +- Stop And Wait와 다르게 ACK이 오기전에 패킷을 전송할 수 있는 방법이다. +- 윈도우 사이즈를 우선적으로 정하고 난 뒤에 ACK이 오기 전까지 데이터를 계속해서 보낸다 + - 도착한 (수신측에서 보낸 ACK)에는 TCP 헤더에 window size를 담아서 보냅니다 + - 도착한 ACK을 온다면 윈도우를 옆으로 옮겨서 다시 다음 패킷을 전송한다 + - 이는 데이터를 다 받을 때 까지 이 과정을 계속 반복을 한다 +image + + +## 혼잡제어 +- 혼잡 제어는 네트워크 내에서 발생하는 혼잡 현상을 관리하고 제어하여 패킷 손실 및 전송 지연을 최소화 하려는 것입니다 + - 라우터가 데이터를 처리하는 속도보다 많은 양의 데이터가 들어온다면, 계쏙해서 데이터를 유실한것으로 생각하고 데이터를 보내 네트워크가 혼잡해집니다. + - 우리는 혼잡제어 기술을 통해, 이러한 송신자의 데이터 전송속도를 조절합니다. +### Cogestion Window +- window의 크기를 조절하면서, 우리는 이런 방식을 해결할 수 있습니다. +- 우선 Additive Increase로 패킷을 보냈는데 문제 없이 도착을한다면 window의 크기를 1씩 늘립니다 + - 이러다 만약, 전송에 실패하게 된다면 Multiplicative Decrease를 통해서 Window의 크기를 **절반**으로 줄입니다. +- 이런방식이 아닌 SLow Start나 Fast Retransmit 방식도 존재합니다 \ No newline at end of file