[CS] 면접질문 대비 - 네트워크

흶·2021년 9월 28일

Network

목록 보기

7/7

✔ Http와 Https 통신 방식의 차이

HTTP + 암호화 = HTTPS

HTTP는 암호화가 추가되지 않았기 때문에 보안에 취약한 반면, HTTPS는 안전하게 데이터를 주고받을 수 있다.

하지만 HTTPS를 이용하면 암호화/복호화의 과정이 필요하기 때문에 HTTP보다 속도가 느리다.(오늘날에는 거의 차이를 못느낄 정도이다.)

또한 HTTPS는 인증서를 발급하고 유지하기 위한 추가 비용이 발생하다.

그렇다면 언제 HTTP를 쓰고, 언제 HTTPS를 쓰는 것이 좋겠는가?
- 개인 정보와 같은 민감한 데이터를 주고 받아야 한다면 HTTPS를 이용해야 하지만, 단순한 정보 조회 등만을 처리하고 있다면 HTTP를 이용하면 된다.

출처

✔ 프록시 서버가 필요한 이유

분산 처리 (캐시 사용, 로드밸런싱) - 캐시된 웹페이지가 있으면 프록시 서버에서 바로 클라이언트에 전송
보안 (요청과 응답의 필터링) - 바이러스 검출, 컨텐츠 차단, 웹서버 방화벽

프록시 서버란? : 클라이언트가 자신을 거쳐 다른 네트워크에 접속할 수 있도록 중간에서 대리해주는 서버 (서버이면서 동시에 클라이언트)

✔ (프록시 서버 사용 시) 페이지의 내용과 데이터의 값이 계속 바뀌면?

캐시 만료기한을 설정함
프록시 서버로 사용자가 요청했을 때 요청한 시각이 프록시에서 다운로드 받은 시간에서 만료기한 이내이면 프록시에서 다운로드를 할 것이고, 그렇지 않다면 다시 실제 서버로 요청을 하게 됨

✔ IPconfig와 Ifconfig는 무엇인지

시스템이 네트워크에 접속되어 있는 인터페이스 (NIC)의 설정 상황을 보여주거나 편집하는 유틸리티 명령어이다.

ipconfig의 경우는 windows에서 사용되는 명령어 이며, ifconfig 유닉스계열의 시스템에서 사용

✔ TCP와 UDP의 특징과 차이점은?

TCP는 양방향, UDP는 단방향
TCP는 연결지향형 프로토콜, UDP는 비연결지향형 프로토콜
TCP는 혼잡제어 및 흐름제어 지원, UDP는 X
TCP는 신뢰성 있는 데이터 전송, UDP는 데이터 전송 보장 X
TCP는 가상회선 패킷 교환 방식, UDP는 데이터그램 패킷 교환 방식
신뢰성이 요구되는 애플리케이션에서는 TCP를 사용하고 간단한 데이터를 빠른 속도로 전송하고자 하는 애플리케이션에서는 UDP를 사용
- TCP : HTTP, Email, File Transfer 등
- UDP : DNS, Broadcasting 등

✔ HTTP의 비연결성을 해결하기 위한 방법?

HTTP 는 '비연결성'과 '무상태' 라는 특성을 지님으로 멀티 쓰레드 환경에서 웹 어플리케이션이 보다 많은 요청과 응답을 할 수 있도록 한다. (상태를 저장해야 하는 서버의 부담을 줄임)

비연결성 해결법

Keep Alive!

무상태 해결법

1. 쿠키
2. 세션

쿠키
- 브라우저 단에서 사용자 정보 저장
- 키-밸류 형태로 웹 브라우저의 쿠키 저장소에 저장
- 이후 웹 서버에 요청을 보낼 때 쿠키를 헤더에 실어서 함께 전송
- 유효기간 설정이 가능 - 유효기간을 설정하면 쿠키는 특정 시간이 지나면 자동으로 소멸, 유효기간을 설정하지 않을 시에는 브라우저 종료와 함께 소멸
- 쿠키는 사용자 정보가 브라우저에 저장되기 때문에 공격자로부터 위변조의 가능성이 높아 보안에 취약
세션
- 서버 단에서 사용자 정보 저장
- 서버는 각 브라우저에 세션 ID 를 전송
- 웹 브라우저는 웹 서버에 연결 시 매번 세션 ID 를 보내서 웹 서버가 어떤 세션을 사용할 지 알 수 있도록 함
- 세션 정보도 중간에 탈취 당할 수 있기 때문에 보안에 완벽하다고 할 수 없음
- 서버에 사용자 정보를 저장하므로, 서버의 메모리를 차지하게 되고, 서버 과부하의 원인이 될 수 있음

=> 쿠키와 세션의 문제점들을 보완하기 위해 토큰( Token )기반의 인증 방식이 도입

참고

✔ 127.0.0.1과 local host가 무엇을 의미하는가?

루프백(loopback) 혹은 로컬호스트 주소(localhost)라고도 불린다.
만약 목적지 IP 주소를 127.0.0.1로 설정하게 되면 A의 네트워크 계층은 이 패킷을 외부로 전송하지 않는다.
즉 자신이 송신한 패킷을 그대로 수신한 효과를 준다.
예약된 주소로 할당할 수 없는 주소이며
자체 IP에서 할당 작동하여 인터넷이 연결되어있지 않아도 작동한다.
127.0.0.1을 치기 귀찮아서 localhost를 쓰게됨

✔ 인터넷, 인트라넷, 엑스트라 넷의 차이점은?

인터넷
- Inter(인터)-연결, International(인터내셔널)-국제적
- 여러개의 네트워크의 연결을 의미
- 각 회사나 단체들이 자신들의 정보를 공유하고자 만들었던 네트워크를 좀더 국제적으로(많은 사람들)과 정보를 공유하려고 서로 연결하기 시작
인트라넷
- Intra(내부의)
- 쉽게말해 내부의 네트워크(회사나 특정 단체들만 사용하는 네트워크)
- 내부적으로만 사용이 가능 : 즉, 회사의 인트라넷이라면 해당 회사가 허가한 사람만 인트라넷에 접속이 가능
엑스트라넷
- 인트라넷에서 범위를 확장시킨것
- 인트라넷은 회사의 직원들만 사용이 가능했다면 엑스트라넷은 회사의 직원은 물론 직원 이외에도 협력회사나 회사의 고객까지 사용할 수 있도록 인트라넷의 범위를 확장시킨것
- 인트라넷보다 좀더 넓은 범위의 사용자들이 이용 가능

✔ 스위치와 허브의 차이점은?

허브
- 물리계층에서 동작
- 전기적인 신호를 증폭시켜 LAN의 전송거리를 연장시키고, 여러 대의 디바이스를 연결해 네트워크를 만들어주는 장비
- 크게 멀티포트와 리피터 두가지 기능으로 많이 사용
  - 멀티포트 : 한번에 많은 디바이스를 연결할 수 있는 기능(허브가 없다면 디바이스는 두 대만 연결 가능)
  - 리피터 : 전기적인 신호를 증폭시켜 들어온 데이터를 재전송
- 허브로 연결된 네트워크에서 하나의 디바이스에서 전송된 데이터 프레임을 허브로 연결된 모든 디바이스에게 전부 전송하는 플러딩이 발생 (불필요한 전송 발생)
  - 결과적으로 충돌이 많이 발생하여 하나의 허브에는 많은 디바이스를 연결할 수 없음
  - 보안성 떨어짐
스위치
- 데이터링크에서 동작
- 자신에게 연결된 디바이스들의 MAC 주소와 포트가 기록된 MAC 주소 테이블을 가지고 있음
- 프레임이 자신에게 오면 그 것의 목적지가 어디인지 파악하여 그 디바이스에게 프레임을 보내기 때문에 트래픽이 훨씬 효율적
- 다만, 스위치는 자신의 테이블에 없는 목적지를 가진 패킷이 오면 해당 패킷을 연결된 모든 장치에 포워딩하는데, 이 경우에는 허브와 동일한 동작
- 데이터의 전송 에러 등을 복구

[정리]
허브는 다른 모든 포트에서 허브로 들어오는 모든 트래픽을 보내는 간단한 장치이다. 이로 인해 네트워크에서 불필요한 트래픽 흐름이 많이 발생하여 충돌이 발생할 수 있다.

반면에 스위치는 연결된 장치에 대한 정보를 수집하고 관련 포트를 통해서만 들어오는 트래픽을 전달한다. 또한 스위치에서 동시 통신을 유지할 수 있다.

따라서 허브는 소규모 네트워크에 적합하고 스위치는 트래픽이 많은 대규모 네트워크에 더 적합하다.

✔ 고정 IP와 유동 IP란?

= 유동IP(Dynamic Host Configuration Protocol, DHCP)와 고정IP(Static IP) 의 차이점

고정 IP 는 사용자 전용으로 부여된 IP 주소로 이를 반납하기 전까지는 IP 정보가 변경되지 않고 사용이 가능하며 다른 장비에서 해당 주소에 대한 사용이 불가하다. IP를 고정시킴으로써 외부에서 동일한 주소로 통신할 수 있기 때문에 이를 방화벽을 통한 통신을 제어하여 관리할 수 있다.

서버

반면 유동 IP는 고정적이지 않고 필요할 때 IP 주소를 할당하여 사용할 수 있도록 한다. 예를 들어 고정 IP 보다 더 많은 사용이 필요한 장비가 있을 경우 유동 IP를 통해 장비를 사용할 때 돌아가면서 IP를 부여하여 사용할 수 있다. 이는 부족한 IP 개수 문제를 해결할 수 있으며 단말기들의 IP 회전율과 가용성을 높여 준다는 장점이 있습니다.

일반 가정 공유기

IP문제를 해결하고자 나온 것이 유동 IP
한 컴퓨터가 사용하지 않을 때 그 IP를 다른 컴퓨터에게 빌려주는 개념!

✔ 안티바이러스 vs 방화벽

안티 바이러스의 종류 : IDS(침입탐지시스템)/IPS(침입방지시스템)
방화벽 : 미리 정의된 보안 규칙에 기반한, 들어오고 나가는 네트워크 트래픽을 모니터링하고 제어하는 네트워크 보안 시스템'

방화벽은 실질적으로 IP/Port 기반으로 차단하는 솔루션이기 때문에 외부에서 내부로 반드시 들어와야 하는 서비스, 예를 들어 웹/메일 서비스와 같은 경우에는 방화벽은 외부에서 누가 들어올 지 정의할 수 없으므로, 관련 서비스 포트를 모두 허용으로 설정해야 한다.

그렇게 되면, 일반 유저뿐만 아니라 악의적인 의도를 가진 해킹/악성코드/스팸메일 등도 여과없이 들어올 수 밖에 없으므로, 이러한 방화벽의 한계점을 보완하기 위해(대체는 아님) 나온 솔루션이 침입 탐지(IDS)/방지(IPS) 시스템이다.

근래에 도입되는 솔루션은 대부분은 IPS

IPS : 침입탐지(Intrusion Detection), 안티 바이러스(Anti-virus)와 같은 Signature 기반의 기술들과 방화벽(Firewall)과 같은 네트워크 기반의 차단 솔루션을 논리적으로 결합한 방식

출처

✔ port란? 사용하는 이유?

IP Address의 한계 : IP Address만을 이용해 컴퓨터로 데이터를 보낸다면 컴퓨터는 그 데이터를 받지만, 문제는 그 데이터가 어느 프로세스에서 처리되어야 하는 것인지를 알 수가 없다.
통신을 해야하는 프로세스는 각자 자신의 Port를 가지고 있고, 해당 Port를 통해 데이터를 받는다.
Port 정보를 통해 어떤 프로세스가 메세지를 받아야 하는지 알 수 있다.
Port는 TCP 계층에서 추가된다.
자주 사용되는 port : 80(http), 443(https), ftp(20,21), ...

✔ 3-Handshaking과 4-Handshaking의 과정은?

<3-handshaking>

Why? 장치들 사이에 논리적인 접속(session)을 성립하기 위해!

클라이언트가 서버에게 SYN 패킷을 보낸다. (sequence : x)
서버가 SYN(x)을 받고, 클라이언트로 받았다는 신호인 ACK와 SYN 패킷을 보낸다. (sequence : y, ACK : x + 1)
클라이언트가 ACK(y+1)를 서버로 보내면 연결이 이루어진다.

SYN: synchronize sequence numbers
ACK: acknowledgment

<4-handshaking>
Why? 세션을 종료하기 위해!

클라이언트가 서버에게 연결을 종료한다는 FIN 플래그를 보낸다.
서버는 FIN을 받고, 확인했다는 ACK를 클라이언트에게 보낸다. (이때 모든 데이터를 보내기 위해 CLOSE_WAIT 상태가 된다)
데이터를 모두 보냈다면, 연결이 종료되었다는 FIN 플래그를 클라이언트에게 보낸다.
클라이언트는 FIN을 받고, 확인했다는 ACK를 서버에게 보낸다. (단, 아직 서버로부터 받지 못한 데이터가 있을 수 있으므로 TIME_WAIT을 통해 기다린다)
서버는 ACK를 받은 이후 소켓을 닫는다 (Closed)
TIME_WAIT 시간이 끝나면 클라이언트도 닫는다 (Closed)

TIME_WAIT: Client가 Server로부터 FIN을 수신하더라도 일정시간(디폴트 240초)동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정

✔ 공개키 암호화 시나리오?

A가 웹 상에 공개된 B의 공개키를 이용하여 평문을 암호화 한다.
이 암호문(CiperText)는 B가 개인적으로 가지고 있는 B의 비밀키로만 복호화가 가능하다. B는 자신의 비밀키로 복호화한 평문을 확인하고, A의 공개키로 응답을 암호화하여 A에게 보낸다.
A는 A의 비밀키로 암호화된 응답문을 복호화한다.

장점 : 대칭키의 단점을 완벽하게 해결함
단점 : 암호화/복호화가 매우 복잡함 (키가 서로 다르기 때문에)

이론적으로 완벽한 암호화 시나리오 (대칭키+공개키)

A가 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화하여 B에게 보낸다.
B는 암호문을 받아, 자신(B)의 비밀키로 복호화한다.
B는 A로 부터 얻은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보낸다.
A는 자신의 대칭키로 암호문을 복호화한다.
계속 대칭키로 암호화 통신을 한다.

=> 이 방식이 바로 SSL(Secure Socket Layer)의 시초

흶

당근먹고 자라나는 개발자

이전 포스트