5주차 후기
스터디원이 바빠서 어제 2명이서 진행했다..ㅎㅎ
그래도 유익하고 재미있었다..!
TCP
3-way Handshake 에 대해 설명해 주세요.
3-way Handshake은 TCP/IP 프로토콜에서 사용되는 연결 설정 과정으로, 클라이언트가 서버에 연결을 요청하고, 서버가 연결을 수락하는 과정입니다.
- 클라이언트는 서버에게 연결을 요청하기 위해 SYN(Synchronize) 패킷을 보냅니다. 이 SYN 패킷은 클라이언트의 TCP 헤더에 SYN 플래그가 설정되어 있어, 서버에게 연결 설정 요청을 보냄을 나타냅니다.
- 서버는 클라이언트의 SYN 패킷을 받고, 연결 수락을 위해 SYN과 ACK(Acknowledgment)를 포함한 패킷을 보냅니다. 이 패킷은 서버의 TCP 헤더에 SYN과 ACK 플래그가 설정되어 있어, 클라이언트에게 연결 수락과 함께 클라이언트의 SYN을 확인함을 나타냅니다.
- 클라이언트는 서버의 SYN과 ACK를 포함한 패킷을 받고, 서버로부터 연결 수락이 확인된 것을 알기 위해 ACK를 보냅니다. 이 ACK 패킷은 클라이언트의 TCP 헤더에 ACK 플래그가 설정되어 있어, 서버에게 연결 수락을 확인함을 나타냅니다.
이렇게 세 번의 패킷 교환을 통해 클라이언트와 서버 간의 연결이 성공적으로 설정되며, 데이터의 송수신이 가능해집니다.
ACK, SYN 어디에 저장하나?
ACK와 SYN은 TCP 패킷의 헤더에 저장됩니다. TCP 헤더에는 여러 개의 플래그(Flag)가 존재하며, ACK 플래그는 패킷이 Acknowledgment(수신 확인)을 나타내고, SYN 플래그는 연결 설정 요청을 나타냅니다.
2-Way Handshaking 를 하지않는 이유에 대해 설명해 주세요.
2-way Handshaking은 연결 설정 과정에서 클라이언트와 서버가 모두 SYN 패킷을 보내는 방식인데, 이는 서로의 요청과 수락이 서로에게 영향을 주는 것을 막기 위한 방법입니다. 만약 2-way Handshaking을 하지 않는다면, 한 쪽이 연결 요청을 보내고 다른 쪽이 연결 수락을 할 때 충돌이 발생할 수 있어 제대로된 연결이 설정되지 않을 수 있습니다.
두 호스트가 동시에 연결을 시도하면, 연결이 가능한가요? 가능하다면 어떻게 통신 연결을 수행하나요?
두 호스트가 동시에 연결을 시도하면, 연결이 가능할 수 있습니다. 이를 동시에 연결 설정 시도하는 상황을 "경쟁 상태"라고 합니다. 일반적으로 두 호스트는 각자의 SYN 패킷을 보내고, 서로의 SYN/ACK 패킷을 받은 후에 ACK 패킷을 보내 연결을 수락하게 됩니다. 이렇게 하면 두 호스트는 동시에 연결을 설정할 수 있습니다.
SYN Flooding 에 대해 설명해 주세요.
SYN Flooding은 공격자가 대량의 가짜 SYN 패킷을 서버에게 보내어 서버가 응답을 기다리는 상태를 만들어 서버의 리소스를 고갈시키는 공격입니다. 공격자는 실제로 연결을 설정하지 않고 SYN 패킷만 보내기 때문에 서버는 연결 설정 요청에 응답을 보내고, 대기상태인 연결 수락을 위한 자원을 낭비하게 됩니다. 이로 인해 서버의 성능 저하나 서비스 거부(Denial of Service) 공격으로 이어질 수 있습니다.
4-way Handshake 에 대해 설명해 주세요.
4-way Handshake은 TCP 연결을 종료하는 과정으로, 클라이언트와 서버 간에 상호간에 연결을 종료하는 과정을 의미합니다. 간략하게 아래와 같은 과정으로 진행됩니다.
- 클라이언트가 서버에게 연결 종료 요청 패킷(FIN)을 보냄.
- 서버가 클라이언트에게 확인 응답 패킷(ACK)을 보냄.
- 서버가 클라이언트에게 연결 종료 요청 패킷(FIN)을 보냄.
- 클라이언트가 서버에게 확인 응답 패킷(ACK)을 보냄.
이렇게 총 4번의 패킷 교환을 통해 연결이 종료됩니다.
패킷이 4-way handshake 목적인지 어떻게 파악할 수 있을까요?
패킷이 4-way Handshake 목적인지 어떻게 파악할 수 있는지에 대해서는 패킷 내의 플래그를 확인할 수 있습니다. TCP 헤더에는 FIN 플래그가 존재하며, 이 플래그가 설정되어 있는 패킷이 연결 종료를 요청하는 패킷임을 나타냅니다.
빨리 끊어야 할 경우엔, (즉, 4-way Handshake를 할 여유가 없다면) 어떻게 종료할 수 있을까요?
빠르게 연결을 종료해야 할 경우에는 "RST"(Reset) 패킷을 사용하여 연결을 강제로 종료할 수 있습니다. RST 패킷은 TCP 연결을 강제로 종료하는 패킷으로, 연결을 즉시 종료하고 통신을 더 이상 진행하지 않는 것입니다.
4-Way Handshake 과정에서 중간에 한쪽 네트워크가 강제로 종료된다면, 반대쪽은 이를 어떻게 인식할 수 있을까요?
4-way Handshake 과정에서 중간에 한쪽 네트워크가 강제로 종료되면, 반대쪽은 이를 인식하지 못할 수 있습니다. 이를 해결하기 위해서는 각각의 TCP 연결에 대해 "Keep-Alive" 메커니즘을 사용하여 상대방의 연결 상태를 주기적으로 확인하고 연결이 종료되었는지 여부를 인식할 수 있습니다.
패킷에 담겨진 헤더 정보?
TCP 패킷에는 TCP 헤더가 포함되어 있습니다. TCP 헤더에는 여러 가지 플래그가 포함되어 있는데, 연결 종료를 나타내는 FIN (Finish) 플래그가 그 중 하나입니다. 연결을 끊는다고 패킷을 보내는 쪽은 해당 패킷의 TCP 헤더에 FIN 플래그를 설정하여 상대방에게 연결 종료를 알리게 됩니다.
연결을 끊는다고 어떤 쪽에서 보낼 때, 더 이상 정보를 보내지 않도록 통제하는 방법?
더 이상 정보를 보내지 않도록 통제하는 방법은 FIN 패킷을 보낸 쪽에서는 상대방으로부터 ACK (Acknowledgment) 패킷을 받을 때까지는 더 이상 데이터를 보내지 않도록 설정하는 것입니다. ACK 패킷은 상대방으로부터 FIN 패킷을 받았음을 확인하는 응답 패킷이며, 이를 수신한 후에는 더 이상 데이터를 보내지 않고 연결을 종료하게 됩니다.
왜 종료 후에 바로 끝나지 않고, TIME_WAIT 상태로 대기하는 것 일까요?
TCP 연결이 종료된 후에도 TIME_WAIT 상태로 대기하는 이유는 네트워크에서 지연된 패킷들이 도착할 수 있기 때문입니다. TCP는 네트워크에서 패킷의 손실, 중복, 순서 변경 등을 처리하기 위해 여러 메커니즘을 사용하고 있습니다. 따라서 연결 종료 시에도 이러한 패킷들이 도착할 수 있고, TIME_WAIT 상태로 대기하는 동안에 이러한 패킷들을 처리할 수 있습니다. 또한, TIME_WAIT 상태로 대기함으로써 이전 연결의 모든 패킷이 완전히 소멸되고 나서 다른 연결에 사용될 포트를 안전하게 재사용할 수 있도록 합니다. 이렇게 함으로써 네트워크 상에서 정확하고 안전한 연결 종료를 보장할 수 있습니다.
HTTP
HTTP에 대해 설명해주세요
HTTP (Hypertext Transfer Protocol)는 웹에서 데이터를 전송하기 위해 사용되는 프로토콜로, 클라이언트와 서버 간의 통신을 담당합니다. 여러 가지 버전과 확장이 있으며, 보안을 강화한 HTTPS (HTTP Secure)도 있습니다.
공개키와 대칭키에 대해 설명해 주세요.
- 공개키 (Public Key): 암호화와 복호화에 사용되는 서로 다른 키를 가진 암호화 방식입니다. 공개키는 공개되어 있어 누구나 알 수 있고, 클라이언트와 서버 간의 통신에서 서버가 클라이언트에게 전달됩니다.
- 대칭키 (Symmetric Key): 암호화와 복호화에 동일한 키를 사용하는 암호화 방식으로, 키의 유출에 노출되어 있기 때문에 보안성이 낮은 단점이 있습니다.
왜 HTTPS Handshake 과정에서는 인증서를 사용하는 것 일까요?
- HTTPS는 HTTP의 보안 버전으로, 데이터를 암호화하여 안전한 통신을 제공합니다. HTTPS Handshake 과정에서는 클라이언트와 서버 간에 인증서가 교환됩니다. 인증서는 서버의 신원을 확인하고, 클라이언트가 서버와 안전한 통신을 수행할 수 있도록 공개키를 제공합니다.
SSL과 TLS의 차이는 무엇인가요?
- SSL (Secure Socket Layer)과 TLS (Transport Layer Security)은 둘 다 암호화 프로토콜로, HTTPS에서 사용됩니다. SSL은 오래된 버전이며 현재는 사용되지 않습니다. TLS는 SSL의 후속 버전으로 보안 강화와 개선이 이루어진 버전입니다.
HTTP/1.1과 HTTP/2의 차이점은 무엇인가요?
- HOL Problem (Head-of-Line Blocking): HTTP/1.1에서는 여러 개의 요청이 동시에 전송되더라도 응답이 도착한 순서대로 처리되어, 하나의 응답이 끝나기 전에 다른 응답이 대기해야 하는 문제가 있습니다. 이를 HOL Problem이라고 합니다.
- HTTP/1.0 vs HTTP/1.1: HTTP/1.0은 각 요청마다 새로운 연결을 맺어야 했지만, HTTP/1.1에서는 지속적인 연결(Persistent Connection)을 지원하여 연결을 유지하고 다수의 요청과 응답을 처리할 수 있습니다.
HOL Problem
HOL Problem (Head-of-Line Blocking): HOL Problem은 HTTP/1.1에서 발생하는 문제로, 여러 개의 요청이 동시에 전송되더라도 응답이 도착한 순서대로 처리되어, 하나의 응답이 끝나기 전에 다른 응답이 대기해야 하는 현상을 말합니다. 이로 인해 효율성이 저하되고, 성능이 떨어질 수 있습니다.
HTTP/1.0 vs HTTP/1.1
- HTTP/1.0은 각 요청마다 새로운 연결을 맺어야 했기 때문에 연결의 오버헤드가 높았습니다. 또한, 지속적인 연결(Persistent Connection)을 지원하지 않아 매번 연결을 새로 맺어야 했습니다.
- HTTP/1.1은 지속적인 연결을 지원하여 연결을 유지하고 다수의 요청과 응답을 처리할 수 있습니다. 또한, 요청/응답 헤더의 압축, 파이프라이닝(Pipelining) 등의 기능을 도입하여 성능을 향상시켰습니다.
HTTP/3.0
- HTTP/3.0은 QUIC(Quick UDP Internet Connections) 프로토콜을 기반으로 한 버전으로, 기존의 TCP를 사용하는 HTTP/1.1과 HTTP/2와 달리, UDP를 사용하여 보다 빠르고 안정적인 데이터 전송을 지원합니다. QUIC은 패킷 손실이나 네트워크 변화에 더 잘 대응할 수 있어, 성능이 향상됩니다. 또한, HOL Problem을 완화하고 멀티플렉싱(Multiplexing) 기능을 지원하여 동시에 여러 개의 요청과 응답을 처리할 수 있도록 합니다.
HTTP 프로토콜의 특징
- Stateless: HTTP는 Stateless 프로토콜로, 클라이언트와 서버 간의 각 요청과 응답이 독립적으로 처리됩니다. 이는 클라이언트가 이전의 요청과 상태 정보를 서버에 저장하지 않고, 모든 정보를 요청마다 전송하여 처리하는 특징입니다.
- Connectionless: HTTP는 Connectionless 프로토콜로, 클라이언트와 서버 간의 연결을 유지하지 않고 각 요청마다 새로운 연결을 맺습니다. 요청과 응답이 한 번 이루어지면 연결이 종료되는 특징을 가지고 있습니다.
HTTPS에 대해 설명해주세요
- HTTPS는 HTTP 프로토콜의 보안 버전으로, HTTP 통신을 암호화하여 보안성을 강화한 프로토콜입니다. HTTPS는 SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 통신 내용을 암호화하고, 서버의 신원을 인증하는 인증서를 사용합니다.
인증서를 사용하는 이유?
- 인증서는 서버의 신원을 인증하는 역할을 합니다. 클라이언트가 서버와 통신을 할 때, 서버의 인증서를 확인하여 신뢰성과 보안성을 보장할 수 있습니다. 인증서를 사용하여 서버의 신원을 검증하고, 중간자 공격과 같은 보안 위협을 방지할 수 있습니다.
공개키, 대칭키 장단점
- 공개키: 공개키 암호화 방식은 공개키와 개인키를 사용하여 데이터를 암호화하고 복호화하는 방식입니다. 장점으로는 보안성이 높아 개인키를 보호하면 안전하게 통신할 수 있다는 점이 있습니다. 단점으로는 암호화와 복호화 과정에서의 연산이 복잡하고 느리다는 점이 있습니다.
- 대칭키: 대칭키 암호화 방식은 동일한 키를 암호화와 복호화에 사용하는 방식으로, 빠르게 데이터를 암호화하고 복호화할 수 있는 장점이 있습니다. 단점으로는 키를 안전하게 공유해야 한다는 점이 있습니다.
Stateless와 Connectionless에 대해 설명해 주세요.
- Stateless: Stateless는 각 요청과 응답이 독립적으로 처리되는 특징을 말합니다. HTTP는 클라이언트와 서버 간의 상태 정보를 저장하지 않고, 모든 요청이 독립적으로 처리됩니다. 클라이언트가 이전 요청과 상태를 서버에 저장하지 않기 때문에 서버의 부하를 줄이고, 확장성을 향상시킬 수 있습니다.
- Connectionless: Connectionless는 클라이언트와 서버 간의 연결을 유지하지 않고 각 요청마다 새로운 연결을 맺는 특징을 말합니다. HTTP는 각 요청마다 새로운 연결을 맺고 요청에 대한 응답을 받은 후에 연결을 종료합니다. 이는 서버의 자원을 효율적으로 관리할 수 있고, 다수의 클라이언트와 연결을 처리할 수 있는 장점을 가지고 있습니다.
왜 HTTP는 Stateless 구조를 채택하고 있을까요?
Stateless 구조를 채택한 이유는 서버의 부하를 줄이고, 확장성을 향상시키기 위함입니다. 클라이언트와 서버 간의 상태 정보를 저장하지 않고 독립적으로 처리함으로써 서버의 자원을 효율적으로 관리하고, 다수의 클라이언트와 연결을 처리할 수 있습니다.
HTTP Persistence Connection
HTTP Persistence Connection은 연결을 유지하는 기능으로, HTTP/1.1부터 도입된 기능입니다. 연결을 유지하면 여러 요청과 응답을 하나의 연결로 처리할 수 있어, 연결을 맺고 끊는 과정의 오버헤드를 줄여 속도를 향상시킬 수 있습니다.
왜 HTTP는 Stateless 구조를 채택하고 있을까요?
- 서버의 부하를 줄이기 위함: HTTP는 각 요청과 응답이 독립적으로 처리되는 Stateless 특징을 가지고 있습니다. 이는 서버가 클라이언트의 이전 요청과 상태를 저장할 필요가 없다는 것을 의미합니다. 서버는 각 요청에 대한 응답을 처리한 후에 해당 연결을 종료하거나, 상태 정보를 저장하지 않고 다음 요청을 처리합니다. 이로써 서버의 부하를 줄일 수 있고, 서버의 자원을 효율적으로 관리할 수 있습니다.
- 확장성을 향상시키기 위함: Stateless 구조는 서버가 상태 정보를 저장하지 않고 각 요청을 독립적으로 처리하기 때문에, 다수의 클라이언트와 연결을 처리하거나 서버를 확장하는 데 유리합니다. 서버는 클라이언트와의 연결을 유지하지 않고 각 요청을 독립적으로 처리하므로, 서버의 확장성을 높일 수 있습니다.
- 또한, Stateless 구조는 서버와 클라이언트 간의 의존성을 낮추는 장점도 있습니다. 서버가 클라이언트의 상태를 저장하지 않고 요청을 처리하기 때문에, 클라이언트가 어떤 상태를 갖고 있는지에 대한 의존성이 낮아집니다. 이는 서버와 클라이언트 간의 느슨한 결합을 가능하게 하며, 시스템의 유연성과 확장성을 높일 수 있습니다.
HTTP Persistence Connection 이 무엇인가요?
HTTP Persistence Connection은 연결을 유지하는 기능으로, HTTP/1.1부터 도입된 기능입니다. 연결을 유지하면 여러 요청과 응답을 하나의 연결로 처리할 수 있어, 연결을 맺고 끊는 과정의 오버헤드를 줄여 속도를 향상시킬 수 있습니다.
TCP의 keep-alive와 HTTP의 keep-alive의 차이는 무엇인가요
- TCP의 keep-alive: TCP의 keep-alive는 TCP 연결을 유지하면서 통신이 없는 경우에도 연결을 유지하는 기능입니다. TCP 연결을 끊지 않고 유지하면, 다음 통신 시에 연결을 다시 맺지 않아도 되어 효율적인 통신이 가능합니다.
- HTTP의 keep-alive: HTTP의 keep-alive는 하나의 연결을 통해 여러 요청과 응답을 처리하는 기능입니다. 연결을 유지하면서 다수의 요청과 응답을 처리할 수 있어, 연결을 맺고 끊는 과정의 오버헤드를 줄이고 속도를 향상시킬 수 있습니다.
Method
GET과 POST의 차이점은 무엇인가요?
- 데이터 전달 방식: GET은 URL에 데이터를 포함하여 요청을 전달하고, POST는 요청의 Body에 데이터를 포함하여 전달합니다. GET은 URL에 데이터가 노출되므로 보안에 취약할 수 있습니다. 반면 POST는 요청의 Body에 데이터를 포함하여 전달하기 때문에, 데이터의 노출이 적어보안성이 높습니다.
- 캐싱: GET은 데이터를 캐싱할 수 있으며, 같은 요청에 대한 응답이 캐시에서 가져와서 처리될 수 있습니다. POST는 요청이나 응답이 캐시되지 않고, 항상 서버에 전달되어 처리되어야 합니다.
- 데이터 길이 제한: GET은 URL에 데이터를 포함하기 때문에 데이터 길이에 제한이 있습니다. 반면 POST는 요청의 Body에 데이터를 포함하기 때문에 데이터 길이에 제한이 없습니다.
Get with body / 안쓰는 이유
HTTP 프로토콜에서는 일반적으로 GET 요청에는 요청의 Body에 데이터를 포함하지 않습니다. 이는 GET 요청의 목적이 리소스를 조회하는 것이고, 서버의 상태를 변경하지 않는다는 Stateless 원칙에 따른 것입니다.
GET 요청에도 Body에 데이터를 포함할 수는 있지만, 이는 일반적인 사용 방법이 아닙니다. 왜냐하면 많은 웹 서버와 프록시 서버가 GET 요청의 Body를 무시하거나, 잘못 처리할 수 있기 때문입니다. 또한, GET 요청의 Body에 데이터를 포함하는 경우에는 데이터가 URL에 노출되지 않고, 보안적인 측면에서 안전하지 않을 수 있습니다.
따라서, GET 요청은 주로 리소스를 조회하는 용도로 사용되고, 요청의 Body에 데이터를 포함하는 것은 권장되지 않습니다. 만약 서버의 상태를 변경해야 하는 경우에는 POST, PUT, PATCH 등의 다른 HTTP 메소드를 사용하는 것이 더 적합합니다.
POST vs PUT, PATCH
- 의도: POST는 새로운 리소스를 생성하기 위해 사용되는 메소드입니다. PUT은 기존의 리소스를 수정하기 위해 사용되는 메소드이며, 해당 리소스가 없으면 새로 생성됩니다. PATCH는 리소스의 일부분만 수정하기 위해 사용되는 메소드입니다.
- 요청의 내용: POST는 요청의 Body에 새로운 데이터를 전달하여 리소스를 생성합니다. PUT은 요청의 Body에 전체 리소스를 전달하여 해당 리소스를 수정하거나 생성합니다. PATCH는 요청의 Body에 일부분만 변경하고자 하는 데이터를 전달합니다.
HTTP Method 에 대해 설명해 주세요.
HTTP Method는 클라이언트가 서버에게 어떤 동작을 원하는지를 나타내는 방식입니다.
- GET: 리소스를 조회하기 위해 사용되는 메소드로, 서버에서 클라이언트에게 데이터를 반환합니다.
- POST: 새로운 리소스를 생성하기 위해 사용되는 메소드로, 서버에 데이터를 전송하여 리소스를 생성합니다.
- PUT: 기존의 리소스를 수정하기 위해 사용되는 메소드로, 서버에 데이터를 전송하여 리소스를 수정하거나 생성합니다.
- PATCH: 리소스의 일부분만 수정하기 위해 사용되는 메소드로, 서버에 데이터를 전송하여 리소스의 일부분을 수정합니다.
- DELETE: 리소스를 삭제하기 위해 사용되는 메소드로, 서버에게 리소스를 삭제하도록 요청합니다.
멱등성에 대해 설명해주세요.
멱등성은 동일한 요청을 여러 번 수행하더라도 결과가 동일하게 유지되는 특성을 말합니다. HTTP 프로토콜에서는 멱등성을 가진 메소드들이 존재합니다.
HTTP Method의 멱등성에 대해 설명해 주세요.
HTTP 메소드의 멱등성은 해당 메소드를 여러 번 수행하더라도 서버의 상태가 변하지 않고, 동일한 리소스에 대한 요청이라면 항상 동일한 응답이 반환되는 특성을 의미합니다. 예를 들어, GET 메소드는 리소스를 조회하는 용도로 사용되며, 서버의 상태를 변경하지 않으므로 멱등성을 가집니다.
GET과 POST의 차이는 무엇인가요?
GET 메소드는 리소스를 조회하는 용도로 사용되며, 서버로부터 정보를 요청하는 데 사용됩니다. POST 메소드는 클라이언트가 서버에게 데이터를 전송하여 리소스를 생성하거나 서버의 상태를 변경하는 데 사용됩니다. 따라서, GET과 POST의 가장 큰 차이는 요청의 목적과 성격에 있습니다.
POST와 PUT, PATCH의 차이는 무엇인가요?
POST, PUT, PATCH는 모두 서버의 리소스를 생성하거나 수정하는 용도로 사용됩니다. 그러나 각각의 차이점은 다음과 같습니다:
- POST: 서버에게 새로운 리소스를 생성하라는 요청입니다. 리소스의 위치는 서버가 자동으로 생성하며, 여러 번 요청하더라도 같은 리소스를 중복해서 생성하지 않도록 구현되어야 합니다. 멱등성을 보장하지 않습니다.
- PUT: 클라이언트가 명시적으로 리소스의 위치를 지정하여 리소스를 수정하라는 요청입니다. 이미 해당 위치에 리소스가 존재하면 수정되고, 존재하지 않으면 새로운 리소스가 생성됩니다. 멱등성을 가지며, 동일한 요청을 여러 번 수행하더라도 같은 결과가 유지됩니다.
- PATCH: 리소스의 일부를 수정하라는 요청입니다. PUT과 유사하게 리소스를 수정하지만, 리소스의 일부만을 수정하므로 요청의 결과가 서로 다를 수 있습니다. 멱등성을 가지지 않습니다.
HTTP 1.1 이후로, GET에도 Body에 데이터를 실을 수 있게 되었습니다. 그럼에도 불구하고 왜 아직도 이런 방식을 지양하는 것일까요?
- GET은 주로 리소스를 조회하는 용도로 사용되는 메소드로, 서버의 상태를 변경하지 않아야 하는 Stateless 원칙에 따라야 합니다. 따라서 GET 메소드에 Body에 데이터를 실어서 요청하는 것은 RESTful API 디자인 원칙과 맞지 않습니다. GET 메소드는 서버에서 리소스를 가져오는 용도로만 사용되어야 합니다.
- GET 요청은 일반적으로 캐싱이 가능하도록 설계되어 있습니다. 하지만 Body에 데이터를 실어서 요청하는 경우에는 캐싱이 어려워지거나 불가능해질 수 있습니다. 캐싱은 네트워크 성능을 향상시키고, 서버의 부하를 줄여줄 수 있는 중요한 기술입니다. 따라서 GET 메소드에 Body에 데이터를 추가하는 것은 캐싱을 제한하고 성능에 부정적인 영향을 미칠 수 있습니다.
- 보안과 개인정보의 이슈가 있습니다. GET 요청은 URL에 파라미터가 노출되는 형태로 요청이 이루어지므로, Body에 데이터를 포함하게 되면 URL에 민감한 정보가 노출될 수 있습니다. 이는 보안과 개인정보 보호에 취약점을 남길 수 있습니다
HTTP 응답코드에 대해 설명해주세요.
- 401 (Unauthorized): 클라이언트가 인증되지 않은 상태로 요청을 보낸 경우 사용되는 응답코드입니다. 클라이언트가 인증을 통해 자격 증명을 제공하면 요청이 허가될 수 있습니다.
- 403 (Forbidden): 클라이언트가 요청한 리소스에 대한 접근 권한이 없는 경우 사용되는 응답코드입니다. 인증은 되었지만, 해당 리소스에 대한 권한이 없는 경우에 반환됩니다.
- 200 (OK): 요청이 성공적으로 처리되었음을 나타내는 응답코드입니다. 요청한 작업이 성공적으로 완료되어 클라이언트에게 요청한 리소스의 내용이나 상태가 반환됩니다.
- 201 (Created): 요청이 성공적으로 처리되었고, 새로운 리소스가 생성되었음을 나타내는 응답코드입니다. 일반적으로 POST 요청에 사용되어 새로운 리소스가 성공적으로 생성되었음을 클라이언트에게 알려줍니다.
401 (Unauthorized) 와 403 (Forbidden)은 의미적으로 어떤 차이가 있나요?
- 401 (Unauthorized)은 클라이언트가 인증되지 않은 상태로 요청을 보낸 경우에 사용됩니다. 즉, 서버가 클라이언트에게 해당 리소스에 접근하기 위해서는 인증을 필요로 함을 알려주는 응답코드입니다. 클라이언트는 인증을 통해 자격 증명을 제공하면 요청이 허가될 수 있습니다. 예를 들어, 사용자가 로그인하지 않은 상태에서 보호된 리소스에 접근하려고 할 때 서버가 401 (Unauthorized) 응답을 반환하여 인증이 필요하다는 것을 알립니다.
- 반면에, 403 (Forbidden)은 클라이언트가 요청한 리소스에 대한 접근 권한이 없는 경우에 사용됩니다. 즉, 서버가 클라이언트에게 해당 리소스에 접근할 권한이 없음을 알려주는 응답코드입니다. 클라이언트가 인증을 통해 자격 증명을 제공하더라도, 서버가 해당 리소스에 대한 권한을 부여하지 않은 경우 403 (Forbidden) 응답을 반환합니다.
- 요약하자면, 401 (Unauthorized)은 인증이 필요한 상태를 나타내며, 403 (Forbidden)은 권한이 없는 상태를 나타냅니다. 401은 클라이언트가 인증을 통해 접근할 수 있는 가능성이 있지만, 403은 접근 자체가 허용되지 않은 상태를 의미합니다.
200 (ok) 와 201 (created) 의 차이에 대해 설명해 주세요.
200 (OK)는 클라이언트의 요청이 성공적으로 처리되었고, 서버가 클라이언트에게 요청한 데이터나 리소스를 제공함을 나타냅니다. 이 응답코드는 주로 GET 요청에 사용되며, 요청된 데이터가 성공적으로 반환되었음을 의미합니다.
반면에, 201 (Created)은 클라이언트의 요청이 성공적으로 처리되었고, 서버가 새로운 리소스를 생성하였음을 나타냅니다. 이 응답코드는 주로 POST 요청에 사용되며, 요청된 리소스가 성공적으로 생성되었음을 의미합니다. 서버는 생성된 리소스의 URI를 응답 헤더에 포함하여 클라이언트에게 알려줄 수 있습니다.
pre-defined 가 안 된 status code?
Pre-defined되지 않은 HTTP 상태 코드도 사용될 수 있습니다. 하지만, 이러한 사용은 표준화되지 않아서 특정 애플리케이션 또는 서비스에서만 사용되며 일반적으로 권장되지 않습니다. 표준 HTTP 상태 코드를 사용하는 것이 인터넷 상에서 일관성을 유지하고, 이해하기 쉽고, 호환성이 높기 때문에 권장됩니다.
HTTP와 HTTPS
HTTP와 HTTPS는 둘 다 인터넷 상에서 정보를 전송하기 위한 프로토콜입니다. 그러나 HTTP는 평문(Plain text)으로 데이터를 전송하는 반면에, HTTPS는 SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security) 암호화 프로토콜을 사용하여 데이터를 암호화하여 보안성을 강화한 프로토콜입니다. 따라서 HTTPS는 보안이 요구되는 경우에 사용되며, 개인정보, 금융정보, 로그인 정보와 같은 민감한 데이터를 전송할 때 사용됩니다.
HTTP 요청/응답 헤더
- HTTP 요청/응답 헤더는 HTTP 프로토콜에서 클라이언트와 서버 간에 전송되는 메타 정보입니다. 요청 헤더는 클라이언트가 서버에게 요청을 보낼 때 요청의 속성이나 설정을 전달하며, 응답 헤더는 서버가 클라이언트에게 응답을 보낼 때 응답의 속성이나 설정을 전달합니다. 이러한 헤더는 키-값 쌍으로 이루어져 있으며, HTTP 요청 또는 응답의 시작 부분에 위치하며, 다양한 헤더 필드가 포함될 수 있습니다.
- 요청 헤더에는 다양한 정보가 포함될 수 있습니다. 예를 들면, 요청 메서드(GET, POST, PUT, DELETE 등), 요청 URI(Uniform Resource Identifier), 호스트 이름, 사용자 에이전트 정보, 콘텐츠 타입, 인증 정보, 캐시 제어 정보, 사용 언어 등이 포함될 수 있습니다. 이러한 요청 헤더는 클라이언트가 서버에게 요청을 보낼 때 요청의 속성이나 설정을 전달하여 서버가 요청을 올바르게 처리할 수 있도록 합니다.
- 응답 헤더에는 다양한 정보가 포함될 수 있습니다. 예를 들면, 응답 상태 코드(200, 201, 404, 등), 콘텐츠 타입, 캐시 제어 정보, 인증 정보, 서버 정보 등이 포함될 수 있습니다. 이러한 응답 헤더는 서버가 클라이언트에게 응답을 보낼 때 응답의 속성이나 설정을 전달하여 클라이언트가 응답을 올바르게 처리하고 필요한 정보를 획득할 수 있도록 합니다.
HTTP와 HTTPS 동작 과정
HTTP의 동작 과정
- 클라이언트(웹 브라우저)가 서버에게 HTTP 요청을 보냅니다. 이 요청은 평문(Plain text)으로 전송됩니다.
- 서버는 클라이언트의 요청을 받고, 요청에 대한 처리를 수행한 후, HTTP 응답을 생성하여 클라이언트에게 전송합니다. 이 응답 역시 평문으로 전송됩니다.
- 클라이언트는 서버로부터 받은 HTTP 응답을 해석하여 요청에 따른 처리를 수행합니다.
HTTPS의 동작 과정
- 클라이언트(웹 브라우저)가 서버에게 HTTPS 요청을 보냅니다. 이 요청은 암호화되어 전송됩니다.
- 서버는 클라이언트의 요청을 받고, 서버의 디지털 인증서를 클라이언트에게 제공합니다. 이 인증서는 서버의 공개키를 포함하고 있습니다.
- 클라이언트는 서버의 인증서를 확인하고, 서버의 공개키를 사용하여 요청 데이터를 암호화하여 서버에게 전송합니다.
- 서버는 클라이언트로부터 받은 암호화된 요청 데이터를 복호화하여 처리합니다.
- 서버는 HTTP 응답을 생성하여 클라이언트에게 전송합니다. 이 응답은 암호화되어 전송됩니다.
- 클라이언트는 서버로부터 받은 암호화된 HTTP 응답을 복호화하여 요청에 따른 처리를 수행합니다.
UDP
TCP와 UDP의 차이점은 무엇인가요?
- 연결 지향성: TCP는 연결을 설정하고 종료하는 과정이 필요한 연결 지향형 프로토콜입니다. UDP는 연결 설정이 필요 없는 비연결형 프로토콜입니다.
- 신뢰성: TCP는 데이터의 전송이 보장되고, 순서가 보장되며, 중복되거나 손상된 데이터를 재전송하는 신뢰성 있는 프로토콜입니다. UDP는 데이터의 신뢰성이 보장되지 않습니다.
- 속도: TCP는 데이터의 신뢰성을 보장하기 위해 재전송과 오류 확인을 수행하므로 일부 오버헤드가 발생합니다. UDP는 데이터의 빠른 전송을 위해 더 작은 오버헤드를 가지고 있습니다.
- 대화형 통신: TCP는 대화형 통신에 적합하며, 데이터의 순서가 중요한 경우에 사용됩니다. UDP는 대용량 데이터를 빠르게 전송해야 하는 경우나 데이터의 순서가 중요하지 않은 경우에 사용됩니다.
HTTP 에서 TCP를 고집하였던 이유 / HTTP/3.0에서는 왜 UDP(QUIC)를 사용하는가?
HTTP에서 TCP를 선택한 이유는 TCP가 신뢰성 있는 연결 지향형 프로토콜이기 때문입니다. 데이터의 신뢰성과 순서가 보장되어야 하는 웹 브라우저와 웹 서버 간의 통신에서는 TCP가 적합하다고 판단되었습니다.
그러나 HTTP/3에서는 UDP(QUIC)를 사용하는 이유는 빠른 전송 속도와 낮은 지연 시간을 제공하기 위해서입니다. UDP를 사용하면 TCP의 재전송이나 오류 확인에 따른 오버헤드를 줄일 수 있어서 더 빠른 데이터 전송이 가능하게 됩니다. 또한 QUIC 프로토콜은 데이터의 암호화와 인증을 제공하여 보안성을 유지하면서 빠른 데이터 통신을 가능하게 합니다.
checksum
Checksum은 데이터의 무결성을 확인하기 위한 과정으로, 데이터를 전송하기 전에 데이터의 일부 값을 계산하여 체크섬 값이라는 결과를 생성합니다. 수신측은 체크섬 값을 이용하여 데이터의 무결성을 확인할 수 있습니다.
TCP / UDP 헤더 차이
- 길이: TCP 헤더의 길이는 보통 20바이트로 고정되어 있지만, UDP 헤더의 길이는 8바이트로 고정되어 있습니다.
- 순서 번호: TCP는 순서 번호를 사용하여 데이터의 순서를 유지하고, 재전송을 제어할 수 있지만, UDP는 순서 번호를 사용하지 않습니다.
- ACK와 확인 응답: TCP는 ACK(확인 응답) 번호를 사용하여 데이터의 정확한 수신을 확인하고, 재전송을 요청할 수 있지만, UDP는 ACK를 사용하지 않습니다.
- 연결 설정과 종료: TCP는 연결 설정 및 종료를 위한 플래그와 제어 비트를 가지고 있지만, UDP는 연결 설정 및 종료를 지원하지 않습니다.
UDP의 실시간 스트리밍 외 다른 예시
- DNS(Domain Name System): DNS는 도메인 이름을 IP 주소로 변환하는데 사용되며, DNS 쿼리와 응답은 UDP를 통해 전송될 수 있습니다.
- VoIP(Voice over IP): 음성 통화와 같은 실시간 통신은 UDP를 사용하여 지연을 최소화하고 실시간성을 보장할 수 있습니다.
- 온라인 게임: 온라인 게임에서는 UDP를 사용하여 게임 데이터의 실시간 전송을 처리하여 빠른 응답성을 확보할 수 있습니다.
TCP 연결에 혼잡제어나 flow control 동작 방식
TCP는 혼잡 제어와 흐름 제어를 통해 신뢰성을 보장합니다.
- 혼잡 제어: TCP는 네트워크 혼잡 상태를 감지하고, 데이터의 전송 속도를 조절하여 네트워크 혼잡을 방지합니다. 혼잡 제어 알고리즘들 중에는 TCP Tahoe, TCP Reno, TCP NewReno 등이 있습니다. 이 알고리즘들은 패킷 손실을 감지하고, 전송 속도를 조절하거나, 재전송을 요청함으로써 혼잡 상태를 관리합니다.
- 흐름 제어: TCP는 수신자가 데이터를 처리할 수 있는 속도에 따라 데이터의 전송 속도를 조절하여 데이터의 너무 빠른 전송을 방지합니다. 수신자는 수신 버퍼의 여유 공간을 통해 송신자에게 흐름 제어 윈도우를 통보하고, 송신자는 이를 기반으로 데이터의 전송 속도를 조절합니다.
TCP 핸드쉐이크
TCP 핸드쉐이크는 연결 설정과 종료를 위한 프로세스로, 클라이언트와 서버 간에 연결을 설정하거나 종료할 때 사용됩니다. TCP 핸드쉐이크는 3-way handshake라고도 알려져 있으며, 세 단계로 이루어집니다. 클라이언트가 서버에 연결 요청을 보내고, 서버가 요청을 수락하면 연결이 설정되고, 이후 데이터의 전송이 가능해집니다. 연결 종료시에도 클라이언트와 서버 간에 핸드쉐이크가 이루어지며, 연결이 정상적으로 종료되었음을 알립니다.
왜 HTTP는 TCP를 사용하나요?
HTTP는 웹 상에서 데이터를 전송하기 위한 프로토콜로, 신뢰성이 중요한 데이터 전송이 필요한 경우에 TCP를 선택합니다. TCP는 데이터의 손실이나 손상을 방지하여 신뢰성 있는 통신을 제공하며, 데이터의 정확한 전송을 보장합니다. 웹 브라우저와 웹 서버 간에 이루어지는 HTTP 통신에서는 데이터의 완전성과 신뢰성이 중요하므로, TCP를 사용하여 데이터의 안정적인 전송을 보장합니다.
그렇다면, 왜 HTTP/3 에서는 UDP(QUIC) 를 사용하나요? 위에서 언급한 UDP의 문제가 해결되었나요?
HTTP/3는 최신 버전의 HTTP 프로토콜로, UDP(QUIC)를 사용합니다. 이는 기존의 TCP를 대체한 것입니다. HTTP/3에서는 QUIC(Quick UDP Internet Connections)라는 프로토콜을 사용하여 데이터를 전송합니다. QUIC은 UDP 기반으로 동작하며, 보다 빠른 연결 설정 및 데이터 전송 속도를 제공합니다. 또한 QUIC은 혼잡 제어와 흐름 제어를 자체적으로 구현하므로, TCP와 같은 혼잡 제어와 흐름 제어를 따로 구현할 필요가 없습니다. 또한, QUIC은 패킷 손실이나 네트워크 변동성이 높은 환경에서도 뛰어난 성능을 발휘할 수 있습니다.
본인이 새로운 통신 프로토콜을 TCP나 UDP를 사용해서 구현한다고 하면, 어떤 기준으로 프로토콜을 선택하시겠어요?
- 요구되는 신뢰성: 데이터의 손실이나 손상이 허용되지 않는 경우에는 TCP와 같은 신뢰성 있는 프로토콜을 선택할 수 있습니다. 데이터의 정확한 전송이 필요한 경우에는 TCP를 고려할 수 있습니다.
- 전송 속도: 데이터의 빠른 전송이 필요한 경우에는 UDP와 같이 신속한 전송 속도를 제공하는 프로토콜을 선택할 수 있습니다. 예를 들어, 실시간 스트리밍 서비스나 게임 등에서는 UDP를 사용하여 빠른 전송을 보장할 수 있습니다.
- 혼잡 제어와 흐름 제어: 혼잡 제어와 흐름 제어를 따로 구현하고 관리해야 하는 경우에는 TCP와 같이 이를 내장한 프로토콜을 선택할 수 있습니다. 그러나 QUIC과 같이 혼잡 제어와 흐름 제어를 자체적으로 구현하는 프로토콜도 존재하므로, 이러한 요소를 고려하여 선택할 수 있습니다.
- 네트워크 환경: 네트워크 환경에 따라 프로토콜을 선택할 수 있습니다. 예를 들어, 패킷 손실이나 네트워크 변동성이 높은 환경에서는 UDP와 같이 손실에 대한 빠른 회복이 필요한 프로토콜을 선택할 수 있습니다.
- 개발 및 유지보수의 복잡성: 프로토콜의 개발 및 유지보수에 따른 복잡성도 고려해야 합니다. TCP와 같이 잘 알려진 프로토콜을 사용하면 개발 및 유지보수의 복잡성이 낮아질 수 있습니다. 반면에, 새로운 프로토콜을 선택하는 경우 개발 및 유지보수에 더 많은 리소스가 필요할 수 있습니다.
Checksum이 무엇인가요?
Checksum은 데이터의 무결성을 검사하기 위한 기술적인 방법으로, 데이터의 일부 또는 전체를 검사하여 오류가 있는지 여부를 확인하는 과정입니다. 체크섬은 데이터의 각 비트를 더하거나 빼서 계산되며, 그 결과는 일정한 길이의 숫자로 표현됩니다. 데이터를 전송하거나 저장할 때 체크섬을 계산하여 체크섬 값과 함께 전송하거나 저장하여, 수신 측에서 체크섬 값을 다시 계산하여 원본 데이터의 무결성을 확인할 수 있습니다.
TCP와 UDP 중 어느 프로토콜이 Checksum을 수행할까요?
TCP와 UDP 중 TCP가 Checksum을 수행합니다. TCP 헤더에는 16비트 체크섬 필드가 있어서 TCP 세그먼트의 무결성을 검사합니다.
Checksum을 통해 오류를 정정하는 것은 불가능합니다. Checksum은 오류가 있는지 여부를 검사하는 기능만을 가지고 있으며, 오류가 검출되면 해당 데이터를 재전송하거나 에러를 처리하는 방식으로 오류를 해결해야 합니다.
그렇다면, Checksum을 통해 오류를 정정할 수 있나요?
- Checksum은 데이터의 무결성을 확인하기 위한 검사 합(또는 검사 값을)으로 사용되며, 오류를 정정하는 기능은 갖고 있지 않습니다. Checksum은 데이터를 전송하기 전에 생성되고, 데이터 수신 측에서도 동일한 알고리즘을 사용하여 Checksum을 다시 계산하여 전송된 데이터의 Checksum과 비교합니다. 이를 통해 데이터의 무결성을 확인할 수 있습니다.
- 만약 Checksum이 일치하지 않는다면, 데이터의 무결성에 오류가 있는 것으로 간주되고, 데이터를 재전송하거나 기타 오류 처리 메커니즘을 통해 오류를 처리해야 합니다. Checksum은 오류를 정정하는 기능은 갖고 있지 않기 때문에, 오류가 발생한 경우 데이터의 재전송이나 다른 오류 처리 메커니즘을 통해 오류를 해결해야 합니다.
TCP가 신뢰성을 보장하는 방법에 대해 설명해 주세요.
- 시퀀스 번호와 확인 응답 번호를 사용하여 데이터의 순서와 전송 여부를 확인합니다.
- ACK와 NACK를 사용하여 수신 측이 데이터를 받았는지 여부를 확인하고, 데이터가 손실된 경우 재전송을 요청합니다.
- 타임아웃과 재전송 메커니즘을 사용하여 데이터의 손실을 감지하고, 재전송을 수행합니다.
- 흐름 제어 기능을 사용하여 송신 측과 수신 측의 데이터 처리 속도를 조절하여 혼잡 제어를 수행합니다.
TCP의 혼잡 제어 처리 방법에 대해 설명해 주세요.
TCP의 혼잡 제어는 네트워크 내의 혼잡 상태를 감지하고, 데이터 전송 속도를 조절하여 네트워크 혼잡을 완화하는 기술입니다. TCP는 혼잡 제어를 위해 세 가지 알고리즘을 사용합니다:
- 슬로우 스타트(Slow Start): 송신 측은 데이터 전송을 시작할 때 처음에는 전송 속도를 느리게 증가시키고, 네트워크 혼잡 상황이 발생하지 않는지 감시합니다. 초기에는 혼잡이 발생하지 않았다면 전송 속도를 지수적으로 증가시킵니다.
- 혼잡 회피(Congestion Avoidance): 혼잡 상황이 발생하면 송신 측은 데이터 전송 속도를 조절하여 혼잡을 완화합니다. 혼잡 회피는 슬로우 스타트의 지수적인 전송 속도 증가 대신, 선형적인 전송 속도 증가를 수행합니다. 혼잡 상황이 감지되면 전송 속도를 조절하여 네트워크 혼잡을 피하고, 혼잡이 풀릴 때까지 전송 속도를 조절합니다.
- 혼잡 제어 회복(Congestion Control Recovery): 혼잡 상황이 지속되면 송신 측은 혼잡 상황이 완화될 때까지 전송 속도를 더욱 감소시킵니다. 이를 통해 네트워크 내의 혼잡 상태를 해결하고, 다시 안정된 전송 속도로 돌아갈 수 있도록 합니다.
OSI 7계층
OSI 7계층에 대해 설명해 주세요.
OSI 7계층은 컴퓨터 네트워크에서 데이터 통신을 위한 프로토콜을 7개의 계층으로 나눈 모델입니다. 각 계층은 특정한 기능과 역할을 수행하며, 하위 계층에서 상위 계층으로 올라갈수록 추상화 수준이 높아집니다. OSI 7계층은 다음과 같이 구성됩니다:
- 물리 계층 (Physical Layer): 데이터를 전기적, 광학적, 기계적인 신호로 변환하여 전송하는 계층입니다. 네트워크의 물리적 연결과 전송 매체에 관련된 기능을 수행합니다.
- 데이터 링크 계층 (Data Link Layer): 물리적으로 연결된 네트워크 장치들 간에 데이터를 안전하게 전송하기 위한 계층입니다. MAC 주소를 사용하여 데이터를 프레임 단위로 전송합니다.
- 네트워크 계층 (Network Layer): 데이터의 출발지에서 목적지로의 전송을 관리하는 계층입니다. 데이터의 경로 선택, 라우팅, 패킷 분할 및 조립, 오류 제어 등의 기능을 수행합니다. IP 프로토콜이 이 계층에서 사용됩니다.
- 전송 계층 (Transport Layer): 두 개의 종단 장치 간의 데이터 전송을 관리하는 계층입니다. 데이터의 신뢰성과 정확성을 보장하기 위한 오류 제어, 흐름 제어, 혼잡 제어 등의 기능을 수행합니다. TCP와 UDP 프로토콜이 이 계층에서 사용됩니다.
- 세션 계층 (Session Layer): 통신하는 두 장치 간의 세션을 설정, 유지, 종료하는 계층입니다. 세션 관리, 동기화, 체크 포인팅 등의 기능을 수행합니다.
- 표현 계층 (Presentation Layer): 데이터의 형식을 변환하고, 데이터의 암호화 및 복호화, 데이터 압축, 인코딩 및 디코딩 등의 기능을 수행합니다.
- 응용 계층 (Application Layer): 사용자가 네트워크에 접근하여 데이터를 송수신할 수 있는 인터페이스를 제공하는 계층입니다. 이메일, 웹 브라우저, 파일 전송 등 다양한 응용 프로그램이 이 계층에서 동작합니다.
Transport Layer 의 역할, 예시
Transport Layer의 역할은 송신측과 수신측 사이의 데이터 전송을 관리하고, 데이터의 신뢰성과 정확성을 보장하기 위한 기능을 수행합니다. 예를 들면, 데이터의 세그먼트화, 오류 제어, 흐름 제어, 혼잡 제어 등이 있습니다. Transport Layer는 송신측과 수신측 간의 통신을 단절시키지 않고 신뢰성 있는 데이터 전송을 보장합니다.
TCP, UDP 헤더의 특징
TCP (Transmission Control Protocol):
- 연결 기반 프로토콜로, 송신측과 수신측 간의 연결을 설정하고, 데이터를 신뢰성 있게 전송합니다.
- 헤더에는 출발지 포트, 목적지 포트, 순서 번호, 확인 응답 번호, 윈도우 크기, 체크섬 등의 정보가 포함됩니다.
- 데이터의 신뢰성을 보장하기 위해 오류 제어, 흐름 제어, 혼잡 제어 기능을 수행합니다.
- TCP는 대부분의 웹 브라우징, 파일 전송, 이메일 전송 등에서 사용됩니다.
UDP (User Datagram Protocol):
- 비연결 기반 프로토콜로, 데이터를 신뢰성 없이 빠르게 전송합니다.
- 헤더에는 출발지 포트, 목적지 포트, 길이, 체크섬 등의 정보가 포함됩니다.
- 데이터의 신뢰성이나 정확성을 보장하지 않기 때문에, 실시간 스트리밍, DNS, 음성 통화 등에서 사용됩니다.
인터넷 4계층
인터넷 4계층은 TCP/IP 프로토콜 스택에서의 네트워크 계층을 의미하며, IP (Internet Protocol) 프로토콜이 사용되는 계층입니다. IP는 네트워크 간의 데이터 패킷 전송을 담당하며, 패킷의 경로 선택과 라우팅을 수행합니다. 또한 IP는 패킷의 출발지와 목적지를 나타내는 IP 주소를 사용하여 데이터를 목적지로 전달합니다.
L3 Switch / Router
L3 스위치:
- 네트워크 계층에서 동작하며, IP 주소를 기반으로 스위칭 결정을 내리는 장치입니다.
- 패킷을 검사하여 목적지 IP 주소를 기반으로 다음 홉 (hop)의 포트를 결정하여 패킷을 전달합니다.
- 스위칭 속도가 빠르며, 대규모 네트워크에서 네트워크 트래픽을 효율적으로 처리합니다.
- 주로 내부 네트워크에서 VLAN(Virtual LAN)을 구성하거나 서브넷(Subnet)을 관리하는 등의 목적으로 사용됩니다.
라우터:
- 네트워크 계층에서 동작하며, IP 주소를 기반으로 패킷을 전달하는 장치입니다.
- 두 개 이상의 네트워크 간의 패킷 전달을 수행하며, 다양한 경로 선택 알고리즘을 사용하여 패킷을 최적의 경로로 전송합니다.
- 네트워크 간의 트래픽을 분리하고, 서로 다른 IP 서브넷 간의 통신을 가능하게 합니다.
- 보안 기능, NAT(Network Address Translation) 기능 등 다양한 기능을 제공합니다.
각각의 Header의 Packing Order
각 계층의 프로토콜에서의 헤더의 패킹 순서는 다음과 같습니다:
- 물리 계층: 헤더가 없음 (비트를 전기 신호로 변환)
- 데이터 링크 계층: 헤더 (Header) - 프레임의 출발지 및 목적지 MAC 주소 정보 등
- 네트워크 계층: 헤더 (Header) - 패킷의 출발지 및 목적지 IP 주소 정보 등
- 트랜스포트 계층: 헤더 (Header) - 세그먼트 또는 데이터그램의 출발지 및 목적지 포트 번호, 흐름 제어, 오류 제어 등의 정보
- 세션 계층: 헤더 (Header) - 세션 설정, 유지, 종료 등의 정보
- 프레젠테이션 계층: 헤더 (Header) - 데이터의 암호화, 압축 등의 정보
- 응용 계층: 헤더 (Header) - 응용 프로토콜에 따라 다양한 정보
3계층 프로토콜 → 왜 IP만 이야기할까?
3계층 프로토콜은 네트워크 계층에 해당하며, 주요 프로토콜로 IP (Internet Protocol)이 사용됩니다. IP는 인터넷에서 데이터를 패킷 단위로 전달하는 프로토콜로, 패킷의 출발지와 목적지를 나타내는 IP 주소를 사용하여 데이터를 목적지로 전달합니다. IP는 인터넷에서 가장 널리 사용되는 프로토콜이며, 다양한 네트워크 장비들이 IP를 기반으로 동작하고 있습니다. 그래서 3계층 프로토콜을 언급할 때 IP를 주로 언급하는 것입니다.
ICMP
ICMP는 인터넷 프로토콜 스위트의 일부로, 네트워크 상태를 모니터링하고 제어하기 위해 사용되는 프로토콜입니다. ICMP는 네트워크에서 발생하는 에러 메시지를 전송하고, 네트워크의 상태를 확인하고, 네트워크 장비 간의 통신을 지원하기 위해 사용됩니다. 예를 들어, 네트워크 장비 간의 통신이 불안정할 때 ICMP를 사용하여 네트워크 상태를 확인하고, 문제를 해결할 수 있습니다. ICMP는 주로 네트워크 관리 및 진단 목적으로 사용됩니다.
ARP
ARP (Address Resolution Protocol):
ARP는 네트워크 장비의 IP 주소를 해당 장비의 MAC 주소로 매핑하는 프로토콜입니다. ARP는 로컬 네트워크에서 IP 주소와 MAC 주소 간의 매핑을 관리하며, IP 패킷을 물리적인 네트워크 주소인 MAC 주소로 변환하는 역할을 합니다. ARP는 네트워크 상에서 장비 간의 통신을 가능하게 하기 위해 사용되며, 네트워크 스위치와 라우터 등에서 사용됩니다.
L3 Switch와 Router의 차이에 대해 설명해 주세요.
- 라우팅 결정 방식: 라우터는 IP 주소를 기반으로 라우팅 결정을 합니다. 라우터는 라우팅 테이블을 사용하여 패킷의 목적지 IP 주소를 검사하고, 최적의 경로를 선택하여 패킷을 전달합니다. 반면에, L3 스위치는 IP 주소뿐만 아니라 MAC 주소도 기반으로 라우팅 결정을 할 수 있습니다. L3 스위치는 라우팅 테이블 뿐만 아니라 MAC 주소 테이블도 사용하여 패킷을 전달합니다. 이는 L3 스위치가 스위치의 빠른 전달 속도와 라우터의 고급 라우팅 기능을 결합한 장점 중 하나입니다.
- 네트워크의 경계: 라우터는 네트워크의 경계에 위치하여 서로 다른 네트워크 간의 패킷을 라우팅하는 역할을 합니다. 라우터는 다양한 인터페이스를 가지고 있어 다양한 형태의 네트워크와 연결이 가능합니다. 반면에, L3 스위치는 스위치처럼 LAN 내부에서 동작하며, 같은 네트워크 대역에서 패킷을 전달합니다.
- 확장성과 성능: 라우터는 보통 고급 라우팅 기능과 다양한 인터페이스를 가지고 있어 다양한 네트워크와 연결이 가능하나, 대규모 네트워크에서의 확장성과 성능이 떨어질 수 있습니다. 반면에, L3 스위치는 스위치처럼 빠른 전달 속도와 네트워크 확장성을 제공하면서도 라우터와 유사한 고급 라우팅 기능을 제공할 수 있어 대규모 네트워크에서의 성능과 확장성이 우수합니다.
- 사용 목적: 라우터는 서로 다른 네트워크 간의 연결과 다양한 라우팅 기능이 필요한 복잡한 네트워크 환경에서 주로 사용됩니다. 반면에, L3 스위치는 LAN 내부에서의 라우팅이 필요한 경우나 네트워크 간의 연결이 상대적으로 단순한 중소규모 네트워크에서 주로 사용됩니다.
각 Layer는 패킷을 어떻게 명칭하나요? 예를 들어, Transport Layer의 경우 Segment라 부릅니다.
- 물리 계층 (Physical Layer): 비트 (Bit)
- 데이터 링크 계층 (Data Link Layer): 프레임 (Frame)
- 네트워크 계층 (Network Layer): 패킷 (Packet)
- 전송 계층 (Transport Layer): 세그먼트 (Segment)
- 세션 계층 (Session Layer): 데이터 (Data)
- 표현 계층 (Presentation Layer): 데이터 (Data)
- 응용 계층 (Application Layer): 메시지 (Message)
각각의 Header의 Packing Order에 대해 설명해 주세요.
- 물리 계층 (Physical Layer): 비트는 0과 1의 이진 데이터로 구성되며, 일련의 비트들이 물리적으로 전기 신호나 광 신호 등의 형태로 변환되어 전송됩니다.
- 데이터 링크 계층 (Data Link Layer): 프레임은 목적지 MAC 주소와 출발지 MAC 주소, 에러 검출을 위한 CRC 등의 정보로 구성되며, 이진 형태로 변환되어 전송됩니다.
- 네트워크 계층 (Network Layer): 패킷은 목적지 IP 주소와 출발지 IP 주소, 라우팅을 위한 TTL (Time-to-Live) 등의 정보로 구성되며, 헤더와 데이터로 분리되어 전송됩니다.
- 전송 계층 (Transport Layer): 세그먼트는 출발지 포트 번호와 목적지 포트 번호, 전송 제어 정보 (예: TCP의 시퀀스 번호, 확인 응답 번호 등) 등의 정보로 구성되며, 헤더와 데이터로 분리되어 전송됩니다.
- 세션, 표현, 응용 계층 (Session Layer, Presentation Layer, Application Layer): 이들 계층에서는 데이터의 단위를 각각 세션 데이터, 표현 데이터, 응용 데이터 등이라고 부를 수 있습니다. 이들 데이터는 각 계층에서 필요한 프로토콜 헤더와 데이터로 구성되어 전송됩니다.
각 Layer의 헤더에는 해당 계층에서 필요한 제어 정보와 데이터에 대한 정보가 포함되어 있으며, 이들 헤더는 계층간에 순차적으로 추가되어 전체 패킷이 구성됩니다. 이렇게 계층별로 헤더와 데이터가 추가되어 전송되는 것을 "헤더의 패킹 오더"라고 합니다.
CORS, Socket, Frame Packet Segment Datagram
CORS(Cross Origin Resource Sharing)란
CORS (Cross-Origin Resource Sharing)란, 웹 브라우저에서 보안 상의 이유로 동일한 출처 (origin)를 가지지 않는 다른 웹 사이트 간에 리소스를 공유하는 것을 허용하는 메커니즘입니다. 웹 애플리케이션에서 다른 도메인, 프로토콜, 포트의 리소스에 접근할 때 발생하는 보안 정책을 우회하기 위한 방법으로 사용됩니다.
CORS 동작원리
CORS 동작 원리는 웹 브라우저에서 보안 상의 이유로 스크립트 등의 리소스 요청이 다른 출처로 보내질 때, 서버는 요청을 검사하고 허용되는 출처에 대해서만 리소스 접근을 허용하는 방식입니다. 이를 위해 브라우저는 HTTP 헤더를 사용하여 요청과 응답에 CORS 관련 정보를 포함하고, 서버는 이를 검사하여 리소스 접근을 허용하거나 거부합니다.
CORS 과정
- 클라이언트가 리소스를 요청하는 웹 사이트와 동일한 출처인 경우, 요청은 허용되고 리소스가 정상적으로 반환됩니다.
- 클라이언트가 리소스를 요청하는 웹 사이트와 다른 출처인 경우, 브라우저는 사전 요청 (preflight request)를 보냅니다. 이는 OPTIONS 메서드를 사용하여 서버에 요청을 보내고, 서버는 해당 요청에 대한 CORS 관련 정보를 응답합니다.
- 브라우저는 서버의 응답을 확인하고, 해당 요청이 허용되는 출처인 경우 실제 요청 (actual request)를 보냅니다. 서버는 이 요청에 대해 정상적으로 처리하고, 리소스를 반환합니다.
Socket.io와 WebSocket의 차이
- Socket.io: Socket.io는 웹 소켓(WebSocket)을 기반으로 하는 실시간 통신을 위한 JavaScript 라이브러리입니다. Socket.io는 웹 소켓을 지원하지 않는 환경에서는 폴링(Polling) 등의 대체 수단을 사용하여 실시간 통신을 지원합니다. 또한, Socket.io는 이벤트 기반의 양방향 통신을 제공하며, 서버와 클라이언트 간의 실시간 데이터 전송을 간편하게 구현할 수 있습니다.
- WebSocket: WebSocket은 웹 브라우저와 웹 서버 간에 양방향 통신을 가능하게 하는 프로토콜입니다. 웹 소켓은 TCP/IP 기반의 소켓 통신을 웹 브라우저에서 사용할 수 있도록 확장한 것으로, 실시간 통신에 적합하며, 서버와 클라이언트 간의 실시간 데이터 전송을 효과적으로 처리할 수 있습니다. 웹 소켓은 브라우저와 서버 간의 연결을 유지하며, 양방향으로 데이터를 주고받을 수 있습니다.
Frame Packet Segment Datagram
Frame, Packet, Segment, Datagram은 데이터 통신에서 사용되는 용어들로, 데이터를 나누고 전송하는 단위를 나타냅니다. Frame(프레임): 데이터 통신에서 전송되는 데이터의 최소 단위를 말합니다.
- Frame(프레임): 헤더(Header)와 페이로드(Payload)로 구성되며, 헤더에는 프레임에 대한 정보, 오류 검출 및 복구를 위한 체크섬 등의 정보가 담겨 있습니다. 프레임은 데이터를 작은 단위로 나누어 전송하고, 수신측에서는 이를 조합하여 원본 데이터를 복원합니다.
- Packet(패킷): 데이터 통신에서 한 번에 전송되는 데이터의 논리적인 단위를 말합니다. 패킷은 출발지와 목적지를 나타내는 헤더와 실제 데이터를 포함하는 페이로드로 구성되며, 네트워크 상에서 데이터가 전송되는 단위로 사용됩니다. 패킷은 네트워크 상에서 독립적으로 전송되고, 도착한 순서와 중복 등이 발생할 수 있습니다.
- Segment(세그먼트): 네트워크에서 데이터를 전송하기 위해 분할된 작은 단위를 말합니다. 데이터가 전송될 때, 큰 데이터를 여러 개의 세그먼트로 나누어 전송하고, 수신측에서는 이를 다시 조합하여 원본 데이터를 복원합니다. 세그먼트는 패킷과 유사한 개념이지만, 특정 프로토콜에서 사용되는 용어일 수 있습니다.
- Datagram(데이터그램): 네트워크에서 독립적으로 전송되는 패킷을 말합니다. 데이터그램은 패킷과 유사한 개념으로, 독립적으로 전송되기 때문에 패킷의 전송 순서가 보장되지 않고, 중복, 손실 등의 상황이 발생할 수 있습니다. 데이터그램은 UDP(User Datagram Protocol)와 같은 비연결형 프로토콜에서 사용되며, 실시간 음성, 비디오 스트리밍 등에 사용될 수 있습니다.
'프로그래밍 > CS' 카테고리의 다른 글
| CS스터디 7주차 - 네트워크2(IP~DNS) (0) | 2023.04.20 |
|---|---|
| 2023 정처기(정보처리기사) 시험 신청 후기 및 좋은 자료 (1) | 2023.04.19 |
| CS스터디 5주차 - 알고리즘 (0) | 2023.04.06 |
| CS스터디 4주차 - 자료구조 (0) | 2023.03.31 |
| 지역성: 시간지역성과 공간지역성 (0) | 2023.03.29 |
댓글