[신입 개발자 기술 면접] 네트워크

 

 

OSI 7계층에 대해 설명해주세요

 

컴퓨터 사이에서 통신할 때 표준 프로토콜을 사용할 수 있도록 ISO에서 개발한 모델입니다. 물리, 데이터링크, 네트워크, 전송, 세션, 표현, 응용 계층으로 구성되어 있습니다.

 

[1계층] 

물리계층은 전기, 물리 신호에 따른 계층이며 단순한 전기적 신호 전달 역할을 합니다.

 

[2계층]

데이터 링크 계층은 P2P 간 신뢰성있는 전송을 보장하기 위한 계층이고 주소값은 MAC Address를 물리적을 할당 받습니다.

 

[3계층]

네트워크 계층은 IP 주소 기반으로 경로를 찾아주는 계층입니다. 라우터를 통해 이동할 경로를 선택하여 IP 주소를 지정하고, 해당 경로에 따라 패킷을 전달합니다.

 

[4계층]

전송 계층은 TCP, UDP 등의 프로토콜을 통해 통신을 활성화 하는 계층입니다. 오류 검출 및 복구, 흐름 제어 등을 수행하며 Port 기반 데이터 세그먼트를 전송합니다.

 

[5계층]

세션 계층은 TCP/IP 세션을 만들고 인증에 따른 권한 부여를 합니다. TLS, SSH 등의 프로토콜/기술이 포함됩니다.

 

[6계층]

표현 계층은 데이터를 빠르고 안전하게 전송하기 위해 데이터 압축, 암호화/복호화 단계입니다. SSL, JPEG, MPEG 등의 프로토콜/기술이 포함됩니다.

 

[7 계층]
응용 계층은 일반적인 응용 서비스를 수행합니다. 즉, 사용자 인터페이스, 전자 우편, 데이터베이스 관리 등의 서비스를 제공합니다. 도착 데이터를 브라우저나 메일, 메신저 같은 수단으로 최종 사용자가 확인하는 단계로 HTTP, HTTPS, SNMP, FTP, POP3 같은 프로토콜이 포함됩니다.

 

각 계층에서 데이터를 전송할 때 각 층마다 별도로 인식할 수 있는 헤더를 붙이게 되는데 이 과정을 캡슐화라고 하며 데이터가 전송 매체를 통해 전송된 후 헤더가 벗겨지게 되는 것을 디캡슐화라고 합니다. 각 계층에서 데이터를 구분하는 PDU(Process Data Unit)은 1 계층은 전기적 신호인 Bit, 2 계층은 Frame, 3 계층은 Packet, 4 계층은 Segment, 5~7 계층은 Application Data가 단위로 구성됩니다.

 

 

왜 계층을 나눴을까요? 

 

계층을 나눈 이유는 통신이 일어나는 과정이 단계별로 파악할 수 있으며 이상이 생기면 해당 계층만 수정할 수 있기 때문입니다.

 

TCP와 UDP에 대해서 설명해주세요 

 

[TCP]

연결형 서비스로 3-way handshaking 과정을 통해 연결을 진행하며 4-way handshaking 과정을 통해 연결을 해제합니다. 또한, 흐름 제어를 통해 데이터 처리 속도를 조절하며 혼잡 제어를 통해 네트워크 내의 패킷 수가 과도하게 증가하지 않도록 방지합니다. 그렇기 때문에 높은 신뢰성을 보장하지만 속도가 비교적 느리다는 단점이 있습니다.

 

[UDP]

비연결형 서비스로 3-way handshaking을 사용하지 않기 때문에 신뢰성이 떨어지는 단점이 있습니다. 하지만 수신 여부를 확인하지 않기 때문에 속도가 빠릅니다.

 

* TCP는 신뢰성이 중요한 파일 전송과 같은 경우에 쓰이고 UDP는 실시간성이 중요한 스트리밍에 자주 사용됩니다.

 

 

흐름제어와 혼잡제어가 무엇인가요? 

 

[흐름제어]

수신 측이 송신 측보다 데이터 처리 속도가 빠르면 문제가 없지만, 송신 측의 속도가 빠를 경우 문제가 생깁니다. 수신 측에서 제한된 저장 용량을 초과한 이후에 도착하는 패킷은 손실될 수 있으며, 만약 손실된다면 불필요한 추가 패킷 전송이 발생하게 됩니다. 즉, 송신 측과 수신 측의 TCP 버퍼 크기 차이로 인해 생기는 데이터 처리 속도 차이를 해결하기 위한 기법입니다. 

 

[혼잡제어] 

데이터의 양이 라우터가 처리할 수 있는 양을 초과하면 초과된 데이터는 라우터가 처리하지 못합니다. 이때 송신 측에서는 라우터가 처리하지 못한 데이터를 손실 데이터로 간주하고 계속 재전송하여 네트워크를 혼잡하게 합니다. 이런 상황은 송신 측의 전송 속도를 적절히 조절하여 예방할 수 있는데, 이것을 혼잡 제어라고 합니다. 

 

* 흐름 제어는 송수신 측 사이의 패킷 수를 제어하는 기능이라 할 수 있으며, 혼잡 제어는 네트워크 내의 패킷 수를 조절하여 네트워크의 오버플로우를 방지하는 기능입니다. 

 

 

흐름제어와 혼잡제어를 하는 방법이 뭐가있을까요?  

 

[흐름제어] 

 

1. Stop and wait 

매번 전송한 패킷에 대해 확인 응답(ACK)를 받으면 다음 패킷을 전송하는 방법입니다. 그러나 패킷을 하나씩 보내기 때문에 비효율적인 방법입니다. 

 

2. sliding window

수신 측에서 설정한 윈도우 크기만큼 송신 측에서 확인 응답(ACK) 없이 패킷을 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어 기법입니다. 최초의 윈도우 크기는 호스트들의 '3 way handshaking'을 통해 수신 측 윈도우 크기로 설정되며, 이후 수신 측의 버퍼에 남아있는 공간에 따라 변합니다. 예를 들면, 송신자는 수신자의 확인 응답을 받기 전까지 데이터를 보내고 수신자 확인 응답을 송신자에게 보내면, 슬라이딩 윈도우 사이즈를 충족할 수 있게끔 윈도우를 옆으로 옮깁니다. 

 

 

[혼잡제어]

 

1. AIMD(Additive Increase / Multiplicative Decrease)

처음에 패킷을 하나씩 보내고 이것이 문제없이 도착하면 window 크기(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜가며 전송하는 방법입니다. 전송에 실패하거나 일정 시간을 넘으면 패킷의 보내는 속도를 절반으로 줄이는 방식입니다.  

 

2. Slow Start (느린 시작)

윈도우의 크기를 1, 2, 4, 8, ...과 같이 지수적으로 증가시키다가 혼잡이 감지되면 윈도우 크기를 1로 줄이는 방식입니다. 이후 혼잡 현상이 발생하였던 window size의 절반까지는 이전처럼 지수 함수 꼴로 창 크기를 증가시키고 그 이후부터는 완만하게 1씩 증가시킵니다.

 

3. Fast Recovery (빠른 회복)

혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형증가시키는 방법입니다. 이 정책까지 적용하면 혼잡 상황을 한번 겪고 나서부터는 순수한 AIMD 방식으로 동작하게 됩니다.

 

 

TCP의 연결과 끊는 과정에 대해서 설명해주세요 

 

 

먼저 tcp 헤더에는 control bit (플래그 비트 , 6비트)가 존재하고 SYN, ACK 비트는 여기에 포함되어있으며 해당 위치의 bit가 1이면 해당 패킷이 어떠한 내용을 담고 있는 패킷인지를 나타냅니다. 

 

SYN : 연결 설정, Sequence Number를 랜덤으로 설정하여 세션을 연결하는 데 사용하며, 초기에 Sequence Number전송

ACK : 응답 확인, 패킷을 받았다는 것을 의미하는 flag 

FIN : 연결 해제, 세션 연결을 종료시킬 때 사용되며, 더 이상 전송할 데이터가 없음을 의미. 4 way handshake에서 사용. 

 

[3way 연결 과정]

 

1. 클라이언트가 서버로 접송을 요청하는 SYN 플래그를 보냅니다. 

2. 서버는 SYN + ACK 플래그를 클라이언트로 응답을 보냅니다.

3. 클라이언트 SYN + ACK 플래그를 확인하고 ACK를 보내며 연결 성립이 진행됩니다.  

 

 

[4way 끊는 과정]

 

1. 클라이언트가 연결을 종료하겠다는 FIN 플래그를 전송합니다. 

2. 서버는 확인 했다는 메세지로 ACK플래그를 클라이언트로 먼저 보냅니다. 

3. 서버는 닫을 준비가 다 된 후 클라이언트에게 FIN 플래그를 보냅니다. 

4. 클라이언트는 ACK 플래그를 보내며 Time-wait 상태가 됩니다. 

 

 

TCP의 연결 과정과 연결 종료 과정 단계가 차이나는 이유가 뭔가요? 

 

Client가 데이터 전송을 마쳤다고 하더라도 Server는 아직 보낼 데이터가 남아 있을 수 있기 때문에 일단 FIN에 대한 ACK만 보내고, 데이터를 모두 전송한 후에 자신도 FIN 메세지를 보내기 때문입니다. 

 

 

만약 Server에서 Fin 플래그를 전송하기 전에 전송한 패킷이 라우팅 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도착하는 상황이 발생하면 어떻게 될까요? 

 

위에서 4way handshake과정 마지막 부분에서 말한 TIME-WAIT을 말한 부분이 답이라고 보면되는데, TCP는 이러한 현상에 대비하여 Client는 Server로부터 FIN 플래그를 수신하더라도 일정시간동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정을 거칩니다. 

 

 

초기 Sequence Number인 ISN을 0부터 시작하지 않고 난수를 생성해서 설정하는 이유가 있나요? 

 

Connection을 맺을 때 사용하는 포트(Port)는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용됩니다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재합니다. 서버 측에서는 패킷의 SYN을 보고 패킷을 구분하게 되는데 난수가 아닌 순처적인 Number가 전송된다면 이전의 Connection으로부터 오는 패킷으로 인식할 수 있습니다. 이러한 문제가 발생할 가능성을 줄이기 위해서 난수로 ISN을 설정합니다.

 

UDP 는 항상 신뢰성을 보장하지 않나요??

 

UDP를 사용하더라도 기존의 TCP가 가지고 있던 기능을 구현할 수 있습니다. 애초에 UDP는 데이터 전송을 제외한 어떤 기능도 정의되어있지 않는 프로토콜이기 때문에 프로토콜 자체적으로 봤을 땐 신뢰성을 보장하진 않습니다. 하지만 다르게 말하면 아무 기능이 없는 백지 상태의 프로토콜입니다. 즉, 이후 개발자가 어플리케이션 구현을 어떻게 하냐에 따라서 TCP와 비슷한 수준의 기능을 가질 수 있습니다. 

 

예를 들어, HTTP/3는 QUIC (Quick UDP Internet Connections) 프로토콜을 사용합니다. QUIC은 UDP를 기반으로 하지만, 신뢰성, 순서 보장, 그리고 흐름 제어와 같은 TCP와 비슷한 기능을 제공합니다. 이를 통해 HTTP/3는 기존의 HTTP/2보다 더 빠른 연결 성립 및 전송 속도를 제공하면서도 데이터의 신뢰성을 보장할 수 있습니다.

 

Cookie , Session, Token에 대해서 설명해주세요

 

Http 프로토콜은 Connectionless와 stateless하다는 특징 때문에 쿠키 세션으로 사용자 인증합니다.

 

[쿠키]

 

쿠키는 클라이언트의 브라우저에 설치되는 작은 기록 정보 파일입니다. 

 

1. 브라우저가 서버에 요청을 보냅니다.

2. 서버는 클라이언트의 요청에 대한 응답을 작성할 때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 Set-Cookie에 담습니다.

3. 이후 해당 클라이언트는 요청을 보낼 때마다, 매번 저장된 쿠키를 요청 헤더의 Cookie에 담아 보냅니다. 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트가 누군지 식별하거나 정보를 바탕으로 추천 광고를 띄우거나 합니다.

 

단점은 브라우저에 정보를 저장하기 때문에 보안에 취약합니다. 

 

[세션]

 

세션은 민감한 인증 정보를 브라우저가 아닌 서버 측에 저장하고 관리합니다. 

 

1. 유저가 웹사이트에서 로그인하면 세션이 서버 메모리(혹은 데이터베이스) 상에 저장되며 세션을 식별하기 위한 Session Id를 기준으로 정보를 저장합니다. 

2. 서버에서 브라우저에게 Session Id를 보내주고 쿠키에다가 Session Id를 저장합니다. 

3. 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request에 Session Id를 쿠키에 담아 전송합니다.

4. 서버는 클라이언트가 보낸 Session Id 와 서버 메모리로 관리하고 있는 Session Id를 비교하여 인증을 수행합니다.

 

서버에 저장되어 보안이 뛰어나지만  서버에서 세션 저장소를 사용하므로  요청이 많아질 수록 서버에 부하가 심해집니다. 

 

[JWT]

 

JWT(JSON Web Token)란 인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미합니다. JWT 기반 인증은 JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별하는 방식입니다.

 

1. 사용자가 ID, PW를 입력하여 서버에 로그인 인증을 요청합니다.

2. 서버에서 클라이언트로부터 인증 요청을 받으면, Header, PayLoad, Signature를 정의합니다. Hedaer, PayLoad, Signature를 각각 Base64로 한 번 더 암호화하여 JWT를 생성하고 이를 쿠키에 담아 클라이언트에게 발급합니다.

3. 클라이언트는 서버로부터 받은 JWT를 로컬 스토리지에 저장합니다. (쿠키나 다른 곳에 저장할 수도 있음) API 요청시 Authorization header에 Access Token을 담아서 보냅니다.

4. 서버는 Header에 담긴 토큰이 서버에서 발행한 토큰인지 일치 여부를 확인하여 일치한다면 인증을 통과시켜주고 아니라면 통과시키지 않습니다. 인증이 통과되면 페이로드에 들어있는 유저의 정보들을 select해서 클라이언트에 돌려줍니다.

5. 클라이언트가 서버에 요청을 했는데, 만일 액세스 토큰의 시간이 만료되면  리프레시 토큰을 이용해서 서버로부터 새로운 엑세스 토큰을 발급 받습니다. 

 

jwt에 대해 말씀하셨는데 jwt를 사용하면 어떠한 장점이 있나요?

 

jwt에는 해당 사용자가 가지고 있는 권한이 들어있기 때문에 따로 세션을 관리하지 않아도 됩니다. 서버는 받은 jwt에 대해 무결성을 검증하고 사용자에게 권한을 인가합니다. 따라서 서버는 사용자마다 세션 id를 가지고 있지 않아도 되기 때문에 서버의 부담이 줄어듭니다. 또한, 세션 기반 인증은 사용자 정보가 서버에 저장되기 때문에 Stateful한 특징을 가집니다. 반면에 토큰 기반 인증은 사용자 정보를 서버에 저장되지 않으므로Stateless 한 특징을 가집니다.

 

하지만, jwt는 서버 입장에서 먼저 할 수 있는 작업이 없습니다. 예를들어, 세션의 경우 사용자의 로그인을 강제로 끊어버릴 수 있지만 jwt는 해당 작업이 어렵습니다. 따라서 완벽한 해결책은 아니고 jwt와 세션을 잘 비교하며 상황에 따라 맞는 것을 사용하는 것이 좋은 것 같습니다.

 

Restful API가 무엇인가요? 

 

자원을 URI 로 표시하고 해당 자원의 상태를 주고 받는 것을 의미합니다. 즉, Rest는 URI를 통해 자원을 표시하고, HTTP METHOD를 이용하여 해당 자원의 행위를 정해주며 그 결과를 받는 것을 의미하는데요. Restful API 이란 REST를 REST 답게 쓰는 것을 의미하며, 만약 CRUD 기능을 전부 POST METHOD로만 처리한다면 Restful 하지 못하다고 표현합니다. 

 

* REST : Representational State Transfer 라는 용어의 약자

 

 

CORS가 무엇인가요?

 

크로스 오리진 리소스 쉐어링의 약자로 다른 Origin으로 요청을 보내기 위해 지켜야하는 정책으로, 원래대로라면 sop에 의해 막히게 될 요청을 풀어주는 정책입니다. 여기서 Origin이라는 것은 프로토콜, 도메인, 포트번호를 합친 부분을 의미하고 SOP는 다른 Origin으로 요청을 보낼 수 없도록 금지하는 브라우저의 기본적인 보안 정책입니다. 다시말해서 cors는 sop를 우회하기 위한 여러가지 방법 중 가장 권장되는 방법입니다. 

 

CSRF가 무엇인가 

 

CSRF란, 한글 뜻으로는 사이트간 요청 위조를 뜻합니다. CSRF는 웹 보안 취약점의 일종이며, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(데이터 수정, 삭제, 등록 등) 을 특정 웹사이트에 요청하게 하는 공격입니다. 예를 들어, 피해자의 전자 메일 주소를 변경하거나 암호를 변경하거나 자금 이체를 하는 등의 동작을 수행하게 할 수 있습니다. 특성에 따라, 공격자는 사용자의 계정에 대한 완전한 제어권을 얻을 수 있을 수도 있습니다.

 

 

HTTP와 HTTPS에 대해서 설명해주세요

 

HTTP (하이퍼텍스트 전송 프로토콜)과 HTTPS (하이퍼텍스트 전송 프로토콜 보안)은 모두 웹에서 데이터를 전송하는 데 사용되는 프로토콜입니다. 

 

[HTTP]

HTTP는 기본 프로토콜로, 웹 서버와 클라이언트(웹 브라우저) 간에 정보를 주고받을 때 사용됩니다. 하지만 HTTP는 암호화되지 않은 텍스트 형태로 데이터를 전송하기 때문에, 제3자가 중간에서 데이터를 가로채기 쉽습니다.

 

[HTTPS]

HTTPS는 HTTP에 SSL/TLS 프로토콜을 사용하여 보안 기능을 추가한 것입니다. 이 프로토콜은 데이터를 암호화하여 전송하기 때문에, 제3자가 중간에서 정보를 가로채도 이해할 수 없게 됩니다. 따라서 HTTPS는 민감한 정보가 포함된 웹 사이트에서 권장되며, 현재 대부분의 웹 사이트는 기본적으로 HTTPS를 사용합니다. HTTPS에는 대칭키 암호화와 비대칭키 암호화가 모두 사용됩니다. 비대칭키 암/복호화는 비용이 매우 크기 때문에 서버와 클라이언트가 주고받는 모든 메세지를 비대칭키로 암호화하면 오버헤드가 발생할 수 있습니다. 그래서 서버와 클라이언트가 최초 1회로 서로 대칭키를 공유하기 위한 과정에서 비대칭키 암호화를 사용하고, 이후에 메세지를 주고 받을 때에는 대칭키 암호화를 사용합니다. 

 

HTTP는 80 port, HTTPS는 443 port를 사용합니다.

 

HTTPS의 동작 과정이 어떻게 되나요? 

 

HTTPS는 대칭키 암호화와 비대칭키 암호화를 모두 사용합니다. 먼저 클라이언트와 서버간에 데이터를 암호화하기 위한 세션키를 교환하는 과정이 진행되는데 이때 비대칭키가 사용되며, 안전하게 세션키를 공유하게 되면 이후에 데이터를 교환하는 과정은 대칭키를 사용하게 됩니다. 즉, 세션키는 대칭키로 만들어집니다.

 

https://velog.io/@osk3856/TLS-Handshake

 

1. 클라이언트가 서버에 접속하면서 다음과 같은 데이터를 보냅니다. (Client Hello)

• 클라이언트 측에서 생성한 랜덤 데이터
• 클라이언트가 지원하는 암호화 방식들 : 클라이언트와 서버가 지원하는 암호화 방식이 서로 다를 수 있기 때문에 상호 간에 어떤 암호화 방식을 사용할 것인지에 대한 협상해야합니다.
• 세션 아이디 : 이미 SSL 핸드셰이킹을 했다면 비용과 시간을 절약하기 위해서 기존 세션을 재활용하게 되는데 이때 사용할 연결에 대한 식별자를 서버 측에 전송합니다.

2. 서버는 응답 데이터를 보냅니다. (Server Hello)

• 서버 측에서 생성한 랜덤 데이터
• 서버가 선택한 클라이언트 암호화 방식 : 클라이언트가 전달한 암호화 방식 중에 서버 쪽에서도 사용할 수 있는 암호화 방식을 선택해서 클라이언트에게 전달합니다. 
• 인증서

3. 클라이언트는 서버의 인증서가 CA에 의해 발급된 것인지 확인하기 위해서 클라이언트 (브라우저)에 내장된 CA 리스트를 확인합니다. CA 리스트에 인증서가 없다면 사용자에게 경고 메시지를 출력합니다. 만약 있다면 CA의 공개키를 이용해 인증서를 복호화 합니다. 복호화에 성공했다면 인증서는 CA 개인키로 암호화된 문서임을 암시적으로 보장됩니다. 

 

4. 클라이언트는 서버의 랜덤 데이터와 클라이언트가 생성한 랜덤 데이터를 조합해서 secret 키를 생성합니다. 이때 사용할 암호화 기법은 대칭키이기 때문에 PreMaster secret 값은 제3자에게 절대로 노출되어서는 안 됩니다. 

 

5. 인증서를 복화화해서 얻은 서버의 공개키로 해당 secret 키를 암호화하여 서버로 전송합니다.

 

6. 서버는 자신이 비공개 키로 복호화 할 수 있습니다.

 

7. 이로써 서버와 클라이언트가 모두 secret 값을 공유하게 되었고 이 값을 이용해서 서버와 클라이언트와 주고 받는 데이터들을 데이터 대칭키 방식으로 암호화한 후에 주고받습니다.

 

 

(추가 내용) CA 인증서 발급 과정

 

1. A라는 서버를 만든 기업이 HTTPS를 적용하기 위해 공개키와 개인키를 만듭니다.

2. 신뢰할 수 있는 CA 기업에게 공개키 관리를 부탁하며 계약을 맺습니다.

3. 계약이 완료된 CA 기업은 A 서버의 공개키, 해당 기업의 이름, 공개키 암호화 방법을 담은 인증서를 만들고 해당 인증서를 CA 기업의 개인키로 암호화해서 A 서버에게 제공합니다.

4. A 기업은 직접적인 공개키가 아닌 암호화된 인증서를 보유하게 됩니다. 

 

 

GET 메서드와 POST 메서드의 차이점에 대해 설명해주세요.

 

[GET]

GET은 데이터를 조회할 때 사용하는 메소드로, URL 파라미터에 요청하는 데이터를 담아 보내기 때문에  HTTP 요청 메시지의 BODY부분이 비어있습니다.

 

[POST]

POST는 데이터를 생성할 때 사용하는 메소드로 데티어 전송 시 HTTP 요청 메시지의 BODY부분에 데이터를 저장하여 전송합니다. 

 

GET은 리소스를 조회한다는 점에서 여러 번 요청하더라도 응답이 똑같기 때문에 멱등이며, POST는 리소스 생성/업데이트 용도이기 때문에 멱등이 아닙니다. 

 

* 멱등: 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질 의미

 

 

http 버전에 대해서 차례대로 설명해주세요

 

[http/1.0]

 

http 1.0에는 헤더 개념이 도입되어 요청과 응답에 추가되며, 메타데이터를 주고받고 프로토콜을 유연하고 확장 가능하도록 개선되었습니다. 또한, Content-Type 도입으로 HTML 이외의 문서 전송 기능이 가능해졌습니다. 하지만 컨넥션 하나 당 요청 하나와 응답 하나만 처리가능합니다. 즉, 서버로부터 요청한 데이터를 가져올 때마다 TCP의 3-way handShake를 진행하기 때문에 RTT(Round Trip Time : 왕복시간)가 증가하는 단점이 있습니다.  

 

* 클라이언트가 보낸 요청을 서버가 처리한 후 다시 클라이언트로 응답해주는 사이클을 RTT(Round Trip Time)

 

[RTT 증가를 위한 해결하기 위한 방법들]

 

이미지 스플리팅

많은 이미지가 합쳐 있는 하나의 이미지를 다운로드 받고, 이를 기반으로 background-image의 position을 이용하여 이미지를 표기하는 방법

 

코드 압축

개행 문자, 빈칸 줄여서 코드 크기 최소화

 

이미지Base 64 인코딩

이미지 파일을 64진법으로 이루저니 문자열로 인코딩 하는 방법. 이 방법을 사용하면 서버와의 연결을 열고 이미지에 대해 서버에 HTTP 요청을 할 필요가 없다는 장점이 있지만 Base64 문자열로 변환할 경우 37% 정도 크기가 더 커지는 단점이 있다.

 

[http/1.1]

 

http 1.1 같은 경우 매번 TCP 연결을 하는 것이 아니라 한 번 TCP 초기화를 한 이후에 Keep-alive라는 옵션으로 여러 개의 파일을 송수신할 수 있습니다. 또한 파이프라이닝이 추가되어 앞 요청의 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내고 그 순서에 맞춰 응답을 받는 방식입니다. 하지만 요청에 대한 응답이 지연되면 다음 두, 세번째 Response는 첫번째 응답 처리가 완료되기전까지 대기하게 되므로 Hol Blocking(Head Of Line Blocking) 문제가 발생하게 됩니다. 또한, header 구조의 중복으로 연속된 요청의 헤더의 많은 중복이 발생됩니다. 

* 참고로 Http/1.0에서도 keep-alive가 있었지만 표준화가 되어있지 않았고 HTTP 1.1부터 표준화가 되어 기본 옵션으로 설정

 

[http/2.0]

 

특징으로 크게 5가지로 http 메세지 전송 방식의 전환, 멀티플렉싱, 스트림 우선순위, 서버 푸쉬, 헤더 압축이 있습니다.

 

1. http 메세지 전송 방식의 전환

기존의 HTTP 메세지는 일반 텍스트 형식이였지만, http 2.0 에선 binary Framing 계층을 추가해서 보내는 메세지를 프레임이라는 단위로 분할하며 추가적으로 바이너리로 인코딩을 합니다. 즉, 바이너리 형식 사용으로 파싱속도 및 전송 속도가 빠르고 오류 발생 가능성이 낮아졌습니다.

 

2. 멀티플렉싱

HTTP 1.1의 파이프라이닝으로 하나의 커넥션에 여러 요청이 가능하지만, 결국 여러 요청을 동시에 처리 응답으로 주지는 못합니다. Multiplexed Streams는 하나의 컨넥션 안에 여러개의 Stream이 존재가능하며 메세지가 프레임으로 나뉘어 요청마다 구분되는 스트림을 통해 전달됩니다. 즉, 프레임이 각 요청의 스트림을 통해 전달되며, 하나의 컨넥션 안에 여러개의 스트림을 가질 수 있게 되어 다중화(Multiplexing)가 가능해졌습니다. 즉, 동시에 여러 요청을 처리하는 것이 가능해졌고 스트림을 통해 각 요청의 응답의 순서가 의미가 없어져서 HOL Blocking이 해결됩니다. . 여러 개의 스트림을 사용하면, 그 중 특정 스트림의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 굴릴 수 있기 때문이다.

 

3. 스트림 우선순위 

리소스의 우선순위를 설정하여 전달하는 것이 가능해졌습니다. 

 

4. 서버 푸쉬

서버 푸쉬는 클라이언트가 요청하기 전에 필요하다고 예상되는 리소스를 Server에서 먼저 요청합니다. 예를 들면, html만 요청했는데 css, js, image를 함께 전송합니다.

 

5. 헤더압축

기존에는 중복된 헤더의 전송으로 오버헤드가 많이 발생했지만 http 2.0에서는 요청과 응답의 헤더 메타데이터를 압축해서  오버헤드를 감소했습니다. 이전에 표시된 헤더를 제외한 필드를 허프만 인코딩을 수행해서 데이터를 압축합니다.

 

* 허프만 코딩은 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트수를 사용하여 표현하고, 빈도가 낮은 정보는 비트수를 많이 사용하여 표현해서 전체 데이터의 표현에 필요한 비트양을 줄이는 원리입니다. (HPACK 압축 형식)

 

[http 3.0]

 

http 3.0은 기존의 http 1.0, http 2.0 과는 다르게 UDP 기반의 프로토콜인 QUIC을 사용하여 통신하는 프로토콜입니다. 

QUIC은 TCP의 handshake 과정을 최적화하는 것에 초점을 맞추어 설계되었고 UDP를 사용함으로써 이를 실현해낼 수 있습니다. TCP의 문제점 중 하나는 클라이언트와 서버 간에 세션을 설정하기 전에 보안 세션을 확인하기 위해 TLS Handshake까지 필요합니다. 즉 TCP는 연결을 생성하기 위해 기본적으로 1 RTT, TLS를 사용한 암호화까지 하려고 하면 TLS의 handshake까지 더해져 총 3번의 RTT가 필요합니다. 반면 QUIC은 첫 연결 설정에 1 RTT만 소요됩니다. 즉, 클라이언트가 서버에 어떤 신호를 한번 주고, 서버도 거기에 응답하기만 하면 바로 본 통신을 시작할 수 있습니다. 이것은 첫번째 Handshake를 거칠 때 연결 설정에 필요한 정보와 함께 데이터도 보내버립니다.  또한, Quick은 HTTP 2.0에서 장점으로 가지고 있던 멀티 플렉싱을 지원하고 있습니다. 

 

 

TCP 헤더를 설명하세요.

 

송신 측과 수신 측의 포트번호, 연결 정보가 기록된 제어 비트, 오류를 검출할 때 사용되는 체크섬, 몇 번째 데이터인지 알려주는 시퀀스 번호, 몇 번째 데이터까지 수신했는지 알려주는 ACK번호, 윈도우 크기 등이 헤더에 저장되어 있습니다.

 

 

DNS에 대해 설명해주세요

 

DNS란 Domain Name Server의 준말로, 전화번호부와 같은 역할을 하는 서버 또는 시스템을 의미합니다. 예를 들어, 'www.google.com'처럼 사람이 쉽게 기억하고 읽을 수 있는 주소(또는 이름)를 컴퓨터가 이해할 수 있는 IP주소로 변환하여 사용자의 컴퓨터가 서버로 접근할 수 있도록 하는 서비스를 제공합니다. 인터넷상의 모든 도메인은 나무를 거꾸로 뒤집은 것과 같은 역트리(Inverted tree)의 계층 구조로 구성됩니다. 예를 들어, 'www.google.co.kr'에서 '.kr' 부터 앞에 있는 도메인들을 순차적으로 각 단계별 서버들을 통해 확인합니다.

 

DNS의 구조는 루트 도메인 -> 1단계 도메인(최상위 도메인) -> 2단계 도메인 -> 3단계 도메인 -> 4단계 도메인(서브 도메인)으로 이뤄져 있습니다.

 

• 최상위 도메인은 국가 최상위 도메인과 일반 최상위 도메인으로 구분되며, '.kr'이 여기에 해당됩니다.
• 2단계 도메인은 '.co'가 여기에 해당됩니다.
• 3단계 도메인은 'google'이 해당됩니다.
• 4단계 도메인은 'www' 호스트명이 해당되며, 주소 체계와 구조에 따라 추가 하위 도메인 계층이 있을 수 있습니다.

 

도메인 이름을 입력하면 먼저 캐시 저장소에서 해당되는 IP주소가 있는지 찾아봅니다. 있다면 바로 IP주소로 접근하고, 없다면 최상위 루트 네임 서버부터 방문합니다. 만약 'www.google.com'을 입력했다면 루트 네임 서버에서는 'com'을 관리하는 네임 서버의 IP주소를 반환합니다. 'com' 네임 서버에서는 'google.com'을 관리하는 IP주소를 반환하고, 'google.com'을 관리하는 네임 서버에 도착하면 'www.google.com'에 대한 IP주소를 알려줍니다. 그 IP주소를 받은 DNS 서버는 요청한 컴퓨터에 IP주소를 반환합니다.

 

 

TCP/IP 4계층에 대해 계층별로 설명하세요.

 

TCP/IP 4계층은 OSI 7계층을 단순화한 모델로 네트워크 액세스 계층, 인터넷 계층, 전송 계층, 응용 계층으로 이루어져 있습니다. 네트워크 액세스 계층은 물리적으로 데이터가 어떻게 전송되는 지를 정의한 계층입니다. 인터넷 계층은 IP 주소를 사용하고 라우팅을 통해 데이터를 목적지까지 정확하게 전달합니다. 전송 계층은 패킷의 오류를 검사하고 재전송을 요구하는 등 통신 노드 간의 전반적인 제어를 담당합니다. 응용계층은 사용자로부터 데이터를 입력받고 처리된 데이터를 보여주는 사용자 응용프로그램 인터페이스 계층입니다.

 

웹 서버와 웹 어플리케이션 서버에 대해 차이를 중점으로 설명하세요.

 

웹 서버는 HTTP 요청을 받아 정적인 웹 페이지 형태로 응답을 처리해 반환하는 프로그램입니다. 반면 웹 어플리케이션 서버는 사용자 요구사항에 맞는 다양한 로직을 처리하여 동적 컨텐츠를 제공하는 역할을 합니다. 처리 속도를 위해 정적인 처리는 웹 서버를 통해 하고, 동적인 처리는 웹 어플리케이션 서버가 담당합니다.

 

 

공인 IP와 사설 IP의 차이에 대해 설명하세요.

 

공인 IP는 ISP(인터넷 서비스 공급자)가 제공하는 IP주소로, 유일한 주소이며 외부에 공개되어 있습니다.

사설 IP는 IPv4의 주소 부족으로 인해 서브넷팅된 IP주소로 사설 IP만으로는 인터넷에 직접 접속할 수 없고, 라우터를 통해서만 인터넷에 접속할 수 있습니다.

 

API GATEWAY

 

외부에서 들어오는 모든 API 요청의 관문(Gateway) 역할을 하는 서버로, 클라이언트가 시스템의 아키텍처를 몰라도 약속된 형태의 API 요청만 보내면 적절한 형태로 응답해주는 서버입니다. 장점으로는 클라이언트의 요청을 일괄적으로 처리하고, 전체 시스템의 부하를 분산시키틑 로드 밸런서의 역할을 수행합니다.

 

 

 

[신입 개발자 기술 면접] 운영체제

[신입 개발자 기술 면접] 데이터베이스

[신입 개발자 기술 면접] JAVA