지나공 : 지식을 나누는 공간
[직무인터뷰] 네트워크 이야기 본문
자주 나오는 질문이라고 들은 건 형광펜 표시했습니다.
대답에 꼭 들어가야 하는 키워드는 컬러펜 표시했습니다.
1번 질문에 대한 꼬리질문은 1-1, 1-2와 같이 정리합니다.
Q. HTTP 특징과 쿠키,세션 사용 이유:
HTTP 프로토콜의 약점을 보완하기 위해 쿠키와 세션을 사용한다.
1. Connectionless 프로토콜 (비연결지향)
클라이언트가 서버에 요청했을 때 그 요청에 맞는 응답을 보낸 후 연결을 끊는다.
2. Stateless 프로토콜 (상태정보 유지 안함)
클라이언트의 첫 번째 통신에서 데이터를 주고 받았다고 해도, 두 번째 통신에서 이전 데이터를 유지하지 않는다.
하지만 매번 페이지를 이동할 때마다 로그인을 다시 하지 않도록 유지되어야 하는 정보가 있기 때문에 stateless 를 대처하기 위해 쿠키와 세션을 사용한다.
Q. 쿠키와 세션의 공통점과 차이점
동작방식은 쿠키와 세션이 참 비슷하다. 왜냐하면 세션도 결국 쿠키를 저장해서 사용하기 때문이다. 하지만 큰 차이점은 저장되는 위치다. 쿠키는 클라이언트에 저장되어서 보내는 역할을 하고, 세션은 서버에 저장되어서 클라이언트에게 알려주는 용도다. 쿠키는 서버의 자원을 전혀 사용하지 않는다. 어차피 클라이언트에 저장되니까...!
하지만 세션은 서버에 저장되어서 그 고유한 id를 가지고 있다. 그래서 서버의 자원을 사용한다.
쿠키는 클라이언트에 저장되어서 서버에 요청할 때 빠른 속도를 내고, 세션은 서버에 정보가 있기 때문에 서버의 처리가 필요해서 쿠키보다 속도가 느릴 수 밖에 없다.
- 공통점 : 웹 통신 간 유지하려는 정보를 저장하기 위해 사용하는 것. 로그인 정보 등
- 차이점 : 저장위치, 저장형식, 용량제한, 만료시점 등이 다름.
- 쿠키 : 개인 PC에 저장됨
- 세션 : 접속 중인 웹 서버에 저장됨
Q. 세션을 쓰면 되는데 왜 굳이 쿠키를 사용하는가?
세션이 쿠키에 비해 보안이 높지만 세션은 서버에 저장되고, 서버 자원을 사용하기 때문에 사용자가 많을 경우 소모되는 자원이 상당하다. 자원관리 차원에서 쿠키와 세션을 적절한 요소 및 기능에 병행 사용해서 서버 자원의 낭비를 방지하고 웹사이트의 속도를 높일 수 있다.
Q. 쿠키에 대하여 설명할 수 있는가?
어떤 웹사이트에 접속했을 때 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 데이터 파일.
HTTP에서 클라이언트의 상태 정보를 클라이언트의 PC에 저장했다가 필요 시 정보를 참조하거나 재사용한다.
사용자 인증이 유효한 시간을 명시할 수 있고, 유효시간이 정해지면 브라우저가 종료되어도 인증이 유지된다.
특징
1. 이름(쿠기 구별용), 값(쿠키이름에 해당되는 값), 만료일, 경로, 정보로 구성되어 있다.
2. 클라이언트에 총 300개의 쿠키를 저장할 수 있다.
3. 하나의 도메인 당 20개의 쿠키를 가질 수 있다.
4. 하나의 쿠키는 4KB 까지 저장 가능하다.
목적
세션관리 : 서버에 저장해야 할 로그인, 장바구니 등의 정보 관리
개인화 : 사용자 선호 테마를 추천하는 것 등등..
트래킹 : 사용자 행동 기록 및 분석
동작방식
1. 클라이언트가 브라우저로 웹페이지 접속 요청
2. 서버가 쿠키를 생성해서 header에 포함시켜서 응답
3. 쿠키 만료 기간이 정해져 있다면 브라우저는 종료되어도 만료 기간만큼 이 쿠키를 저장하고 있다가
4. 같은 웹페이지에 접속을 요청할 때 header에 이 쿠키를 같이 보내고
5. 서버는 이 쿠키를 읽어서 이전의 상태 정보를 변경해야 할 때 쿠키를 업뎃한다.
쿠키의 사용 예
- 방문했던 사이트에 다시 방문할 때 아이디와 비밀번호 자동 입력
- 팝업창을 통해 "오늘 이 창을 다시 보지 않기" 체크
Q. 세션을 설명할 수 있는가?
일정 시간 동안 같은 브라우저(사용자)로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 일정하게 유지시키는 기술.
여기서 일정 시간은 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점으로부터 웹 브라우저를 종료하여 연결을 끝내는 시점이다.
즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 한다.
특징
1. 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장한다.
2. 브라우저를 닫거나, 서버에서 세션을 삭제했을 때만 삭재되므로 쿠키보다 비교적 보안이 좋다.
3. 저장 데이터에 제한이 없다. (서버 용량이 허용하는 한)
4. 각 클라이언트에 고유 Session ID를 부여한다. SessionID로 클라이언트를 구분해서 이에 맞는 서비스를 제공한다.
동작방식
1. 클라이언트가 서버에 접속을 요청하면
2. 서버는 클라이언트의 쿠키(request의 header임)를 확인해서 클라이언트가 해당 Session ID를 보냈는지 확인한다.
3. 만약 클라이언트로부터 온 Session ID가 없다면 서버는 해당 클라이언트만의 고유 Session ID를 생성해서 이를 response header인 session-cookie값으로 Session ID를 넣어서 응답한다.
4. 서버로부터 발행된 Session ID는 해당 서버와 클라이언트(브라우저)의 메모리에 저장된다.
5. 클라이언트가 접속을 종료하면 서버 메모리에 저장되어 있는 Session ID는 소멸된다.
1. 클라이언트가 서버에 접속할 때 세션 ID를 발급 받는다.
2. 클라이언트는 서버로부터 받은 세션 ID를 쿠키를 사용해서 갖고 있는다. 저장한다.
3. 클라이언트가 해당 서버에 다시 요청할 때 이 쿠키의 세션ID를 서버에 전달한다.
4. 서버는 세션 ID를 전달 받아서 별다른 작업 없이 세션 ID를 가지고 해당 세션에 있는 클라이언트의 정보를 가져온다.
5. 가져온 클라이언트의 정보를 통해 서버에서는 요청을 처리하고 클라이언트에 응답한다.
세션의 사용 예
화면을 이동해도 로그인이 풀리지 않고 로그아웃 전까지 유지
Q. http://www.naver.com 입력 시 일어나는 일이 뭔가? 웹 동작방식을 설명해봐라.
1,2 - 사용자가 웹브라우저에 웹페이지 URL을 입력함.
3 - DNS 서버에 가서 사용자가 입력한 URL 주소 중 domain name 부분을 검색함.
4 - DNS 서버로부터 해당 도메인 네임에 해당하는 IP 주소를 찾아서 사용자가 입력한 URL 정보와 함께 전달함.
5,6 - 웹페이지 URL 정보와 전달받은 IP 주소를 가지고 http 프로토콜을 사용해서 http 요청 메시지를 생성한다.
이렇게 생성된 http 요청 메시지는 tcp 프로토콜을 사용해서 인터넷을 거쳐서 해당 IP 주소의 컴퓨터로 전송된다.
7 - 이렇게 도착한 http 요청 메시지는 http 프로토콜을 통해 웹페이지 URL로 변환된다.
8 - 웹 서버는 도착한 웹페이지 URL 정보에 해당하는 데이터를 검색해서,
9,10 - 검색된 웹페이지의 데이터에 대해 또다시 http 프로토콜을 사용해서 http 응답 메시지를 생성한다.
이렇게 생성된 http 응답메시지는 tcp 프로토콜을 사용해서 인터넷을 거쳐 원래의 컴퓨터로 전송된다.
11 - 도착한 http 응답 메시지는 http 프로토콜을 사용해서 웹페이지 데이터로 변환된다.
12 - 변환된 웹페이지 데이터는 웹 브라우저에 의해 출력되어 사용자가 볼 수 있게 된다.
*DNS (Domain Name Server) : www.naver.com을 을 치면 이 영어 값을 실제로 가야 할 IP 주소(123.11.123.123.)를 준다.
Q. OSI 7 Layers가 뭔가?
네트워크에서 통신이 일어나는 과정을 표현하기 위해 7단계로 나눈 통신모델 표준.
통신을 하려면 뭘 해야한다고 적은 것이다.
Q. 무슨 계층에서 뭐하는지 아는가?
응용계층에서 내려온 데이터부터 시작해서 계속 헤더가 붙는다. 이 헤더에는 그 계층에 대한 정보가 기록되어 있다.
우리가 이메일을 보낸다고 할 때 처음 응용계층에서 헤더를 붙여 하위 계층으로 넘겨준다. 표현 계층은 응용계층에서 내려온 헤더와 이메일 데이터를 하나의 데이터로 간주하고, 다시 자신의 헤더를 붙인다. 이런 과정을 Encapsulation이라고 한다. 이런 식으로 물리 계층까지 내려오면 그때부터 0과 1의 이진 비트가 전송된다.
받은 수신자는 거꾸로 물리 계층에서 시작해서 헤더의 정보를 확인하고 떼어낸다. 그리고 상위 계층으로 데이터를 전달한다. 이렇게 헤더를 떼어내는 과정이 Decapsulation이다.
물리계층
주로 전기적, 기계적, 기능적인 특성을 이용해 데이터를 전송한다. 데이터는 0과 1의 비트열, On/Off의 전기적 신호 상태로 이루어져 있다.
데이터링크계층
물리계층에서 송수신되는 정보의 오류와 흐름을 관리하여 안전하게 정보의 전달을 수행할 수 있도록 돕는다.
데이터 링크 계층의 데이터 정보 전송은 Point to Point 간이다.
안전한 정보의 전달이라는 건 오류나 재전송하는 기능을 갖고 있다는 것이다.
특히 MAC 주소를 갖고 있어서 통신을 할 수 있다. (MAC 통신)
네트워크계층
중요한 기능을 한다. 목적지까지 가장 안전하고 빠르게 데이터를 보내는 기능인 라우팅을 한다.
즉, 최적의 경로를 설정해야 하는 계층이다. (IP 통신)
전송계층
양 끝단의 사용자들이 신뢰성 있는 데이터를 주고 받게 하는 역할.
송신자와 수신자 간의 신뢰성 있고 효율적인 데이터를 전송하기 위해 오류를 검출하고 복구하며 흐름 제어와 중복 검사 등을 수행한다.
중요한 게, 데이터 전송을 위해 포트번호가 사용된다. 대표 프로토콜로는 TCP와 UDP가 있고, 이 계층에서 사용하는 데이터 단위를 세그먼트라고 한다.
세션계층
응용 프로세스가 통신을 관리하기 위한 방법을 정의한다.
세션을 만들고 없애는 역할을 한다.
표현계층
데이터를 어떻게 표현할지 정하는 역할을 하는 계층으로 일종의 확장자라고 이해할 수 있다.
세 가지 기능을 갖고 있는데,
1. 송신자에서 온 데이터를 해석하기 위해 응용계층 데이터를 인코딩.
(데이터를 처리를 위한 방식으로 변환, 압축하는 게 인코더, 이걸 다시 원래 형태로 변환하는게 디코더)
2. 수신자에서 데이터의 압축을 풀 수 있는 방식으로 된 데이터를 압축
3. 데이터의 암호화와 복호화
응용계층
사용자와 가장 가까운 계층으로, 우리가 사용하는 응용 서비스나 프로세스가 응용 계층에서 동작한다.
Q. TCP/IP 4 Layer가 뭔가?
인터넷 프로그램들이 서로 통신하는 데 있어 여러 프로토콜이 있다. 인터넷 프로토콜에서 가장 많이 사용하는 것은 IP이다. 잊지 말아야 하는 건, TCP/IP는 프로토콜이라는 것이다. 계층 아님! 하튼 현재의 인터넷에서 컴퓨터들이 서로 통신을 주고 받는데 쓰이는 프로토콜의 모음이라고 이해하면 된다.
네트워크 인터페이스 계층
Node - To - Node 간 신뢰성 있는 데이터 전송을 담당한다.
OSI 7계층의 물리 계층과 데이터링크 계층의 역할을 여기서 담당한다.
따라서 데이터링크 계층에서 사용되는 MAC 주소가 여기서 사용된다.
이런 랜 카드가 있어야만 통신을 할 수 있는데 이게 바로 네트워크 인터페이스 계층에서 동작하는 장비이다.
이런 LAN에서 동작하는 프로토콜은 Ethernet(이더넷)이 있다.
인터넷 계층
OSI 7계층의 네트워크 계층을 담당한다. OSI 7계층처럼 호스트 간의 라우팅을 담당한다.
인터넷 계층에서 동작하는 프로토콜로는 IP가 있다. 비신뢰성, 비연결지향 프로토콜이다. IP는 데이터 재조합이나 손실 여부를 확인할 수 없고 단순히 전달만 하는 프로토콜이다.
전송 계층
OSI 7계층의 전송 계층과 같다. 프로세스 간 신뢰성 있는 데이터 전송을 담당하고, process - to - process 전송을 위해 논리적 주소인 포트번호를 사용한다. 전송 계층의 프로토콜은 TCP, UDP가 있다.
응용 계층
사용자와 가장 가까운 계층으로, OSI 7계층의 5-7계층의 기능을 담당한다.
서버나 클라이언트 응용 프로그램이 이 계층에서 동작하고, 우리가 알고 있는 브라우저가 이 계층에 해당한다.
전송 계층의 주소인 포트번호를 사용한다. 예를 들어 HTTP는 포트번호를 80번으로 사용한다.
- 프로토콜은 뭐가 있는가?
HTTP : TCP 기반의프로토콜로 포트번호 80번을 사용한다.
SSH : 텔넷과 같은 서비스는 비밀번호가 암호화되지 않고 그대로 노출되어 보안이 취약하다. 이걸 보안한 게 SSH로 포트번호 22번을 사용한다.
FTP : 파일 전송 프로토콜로 파일을 받거나 올릴 때 사용한다.
Q. TCP와 UDP의 차이가 뭔가?
패킷 교환 방식 외에는 다 외워두는 게 좋다. TCP는 연결이 되어 있으니 수신 여부를 확인할 수 있고, UDP는 연결이 안되어 있으니 수신 여부를 확인할 수가 없다. TCP는 한명이랑만 손잡고 있으니까 통신이 1:1 밖에 안된다.
Q.TCP와 UDP가 사용되는 예시와 왜 해당 서비스에 각각의 프로토콜이 사용되는지 말할 수 있나?
- Unicast ( TCP 기반)
1대 1로 내가 쏜 걸 너가 잘 받았는가
- Broadcast / Multicast / 동영상 스트리밍 (UDP 기반)
브로드캐스트 방송국은 하난데, 전송은 여러 곳에 한다. 멀티캐스트는 브로드캐스트 중에서 내가 원하는 특정 애들한테만 보내는 것임. 방송국에서 방송 전파를 막 뿌리는 게 아니라 나는 이 동네에만 보내겠다 이런 식으로 한정 짓는 게 멀티캐스트인데 이런 통신 방식은 모두 UDP 이다.
자, 왜 동영상에 UDP가 쓰일까?
1. 일단 UDP가 빠름.
2. 동영상은 1:1 통신이 아니지? 유투버가 방송을 하면 방송이 한명만 들어오고 끝나지 않잖아. 1대 다가 가능해야 하니까 당연히 동영상 스트리밍은 UDP다.
자, 왜 파일전송에 TCP가 쓰일까?
TCP는 신뢰성이 보장된다. 파일 같은거 전송할 때 사용된다. 파일이 전송되다가 중간에 깨졌는데 이걸 신경 안쓰고 막 보내면 안되겠지?
Q. 3-way, 4-way handshaking에 대해 설명해줄 수 있는가?
3-way-handshaking :
TCP통신으로 데이터를 전송하기 위해 네트워크 연결을 설정하는 과정. TCP는 연결형이니까 쓰이는 거고 장치 간 연결하는 거니까 당연히 UDP에는 안 쓰인다.
양쪽 모두 데이터를 전송할 준비가 되었음을 보장하고 실제로 데이터 전달이 시작되기 전에 한 쪽에서 다른 쪽이 준비되었는지 알 수 있게 한다.
1. 클라이언트가 서버에게 연결 요청 메시지 전송한다. (SYN 플래그)
포트 상태는 서버는 LISTEN, 클라이언트는 CLOSED
2. 서버는 syn 플래그를 받고 클라이언트에게 요청을 수락한다는 ack과 syn flag가 설정된 패킷을 같이 발송한다.
(syn을 같이 보내는 이유는 내가 보낸 것에 대해 온 게 맞는지 확인하는 용도)
포트 상태는 서버는 SYN_RCV, 클라이언트는 CLOSED
3. 클라이언트가 다시 서버에게 ack을 보내면 연결이 이루어지면서 이 단계에서 데이터가 전송된다.
포트 상태는 서버와 클라이언트 모두 ESTABLISHED.
4-way-handshaking :
TCP의 연결을 해제하는 과정. TCP에서 장치 간의 세션을 종료하기 위해 사용한다.
1. 클라이언트가 연결을 종료하겠다는 FIN 플래그를 전송한다.
서버가 FIN 플래그로 응답하기 전까지 연결 유지한다.
2. 서버는 확인 메시지 ACK을 보내고 자기가 전송할 데이터가 남아있으면 이걸 이어서 계속 보낸다. 서버의 남은 통신이 끝날 때까지 클라이언트가 기다리는데 이게 TIME_WAIT 상태다.
3. 서버가 통신이 끝나면 연결이 종료에 합의한다고 클라이언트에게 FIN 플래그를 전송한다.
4. 클라이언트는 이 플래그를 확인 했다고 ACK 를 전송한다. 그럼 서버에서 이 값을 받고 close를 시킨다.
Q. HTTP 통신이 뭔가?
프로토콜인데, 클라이언트의 request가 있을 때만 서버가 response해서 해당 정보를 전송하고 곧바로 연결을 종료하는 방식이다. HTTP 프로토콜의 특징은 아까 위에서 말했듯 connectionless랑 stateless가 있다. 각각 요청에 맞게 응답 보내면 그 후 연결을 끊는 특성과 상태를 유지하지 않는, 첫 통신에서 데이터를 주고 받은 뒤 두 번째 통신을 할 때 이전 데이터를 유지하지 않는 특성이다.
Q. REST API가 뭔가?
약자는 잘 안물어본다....
클라이언트와 서버 통신 방식 중 하나로, HTTP URI를 통해서 자원을 명시하고, HTTP 메소드로 행위를 적용하는 아키텍처이고, 이 아키텍처를 준수해서 설계한 API를 Restful API라고 한다.
RESTful 하게 URL를 설계해 본다면.....
1. 소문자를 사용한다. 카멜이 아닌 post-comments 이런 방식으로. (언더바가 아닌 하이픈이라 스네이크 케이스라고는 못하겠다.)
2. 언더바 대신 하이픈 사용 (-)
3. 마지막에 슬래시를 포함하지 않는다.
4. 행위는 포함하지 말자. (동사..) 자원만 표시하자.
5. 파일 확장자는 URI에 포함하지 말자.
6. 전달하려는 자원을 명시하되, 자원을 컨트롤하기 위한 자원이라면 예외적으로 동사를 허용하기도 한다.
posts/duplicating 대신 posts/duplicate을 쓰자. 중복 게시글을 찾는 uri 일 때.
Method를 보자.
1. GET : 리소스를 조회한다.
@RequestParam을 쓰면 쿼리스트링이 주소창에 다 보여서 보안성이 떨어진다.
2. POST : 리소스를 생성한다.
주소창에 데이터 정보가 노출되지 않아서 get에 비해 보안성이 좋다.
3. PUT : 리소스를 수정한다.
4. DELETE : 리소스를 삭제한다.
Q. GET/POST 차이?
[데이터 노출여부]
GET은 URL에 데이터가 노출되는데 POST는 노출되지 않는다.
get : /boardList?name=제목&contents=내용
post : /addBoard
[데이터의 위치]
GET은 헤더에, POST는 바디에 있다.
[전송 길이 제한]
GET은 제한이 있고, POST는 없다.
[캐싱 가능 여부]
GET은 캐싱이 가능하고, POST는 안된다.
*캐싱이란, 한번 접근 후에 또 요청할 때 빠르게 접근하기 위해 데이터를 저장시켜 놓는 것이다. GET을 할 때 가져온 데이터를 저장해두고 두고두고 쓴다.
Q. PUT/PATCH의 차이?
PUT은 자원을 전체 수정할 때 사용하고 PATCH는 자원의 일부를 수정할 때 사용한다.
따라서 DB의 특정 칼럼만 수정하려 하면 PATCH를 사용하고, 그게 아니라 전부 다 수정이면 PUT을 사용한다.
Q. HTTP와 HTTPS 의 차이. 왜 HTTPS를 사용하는가?
HTTPS가 뭐냐고 묻는다면, HTTP에 SSL을 더해서 보안성을 강화했다고 하면 된다.
HTTP는 비연결성이고(위에서 말함) 기본적으로 평문 통신이다. 평문 통신은 내가 검색을 하면 뭘 검색했는지 그대로 다 나온다. 아이디 비번을 바디에 넣어서 POST를 보냈는데 그 바디를 열었을 때 아이디랑 비번이 다 보이게 되는 것이다. 그렇기 때문에 당연히 보안에 취약하다. 보안성을 높이기 위해 HTTPS를 사용한다.
Q. 보안을 어떻게 향상시키는가? SSL의 원리를 말할 수 있는가?
SSL을 활용한다.
일단 키워드는 대칭키, 공개키, 인증서이고 이 단어가 들어가야 한다. 해당 용어에 대해 먼저 이해해보자.
공개키 방식 :
a키로 암호화를 하면 b키로 복호화를 할 수 있다.
b키로 암호화를 하면 a키로 복호화를 할 수 있다.
a와 b 둘 중 하나가 비밀키(=개인키)이고 이는 자신만 갖고 있는다. 공개 안한다.
나머지 하나는 공개키이다. 타인에게 제공이 되는 것이다.
공개키는 유출이 되어도 비밀키를 모르면 복호화를 할 수 없으니까 안전한 것이다.
대칭키 방식 :
암호화를 할 때 사용하는 비밀번호가 있는데 이를 키(key)라고 한다.
대칭키는 동일한 키 하나로 암호화와 복호화를 모두 할 수 있다.
근데 대칭키가 매번 랜덤으로 생성되기 때문에 다음에 사용할 수가 없다. 그래서 안전하다.
그리고 공개키보다 빠르다.
SSL은 공개키 방식과 공개키의 느리다는 단점을 보완한 대칭키 방식을 모두 사용한다.
공개키 방식으로 대칭키를 전달하고, 서로 공유된 대칭키를 가지고 통신하게 된다.
SSL 방식을 적용하려면 인증서를 발급 받아서 서버에 적용해놔야 한다. 인증서는 사용자가 접속한 서버가 우리가 원하던 서버가 맞는지 보장하는 역할을 한다. 이런 인증서를 발급하는 기관을 CA라고 부른다. 공인인증기관의 경우 브라우저가 미리 CA의 리스트와 각 CA별 공개키를 알고 있다.
SSL 동작 방식
1. 사용자가 웹브라우저로 사이트에 접속하면 웹 서버는 인증서를 웹 브라우저에게 보낸다. 이 인증서에는 인증기관의 비밀키로 암호화된 사이트의 정보와 공개키가 들어있다.
2. 웹 브라우저는 이미 갖고 있는 인증기관의 공개키로 웹 서버에서 받은 인증서(비밀키)를 복호화해서 확인한다.
3. 웹 브라우저는 실제 데이터의 암호화에 사용될 대칭키를 생성하고, 인증서에서 꺼낸 웹 서버 측의 공개키로 이를 암호화해서 웹 서버로 보낸다.
4. 웹 서버는 자신이 갖고 있는 비밀키로 웹 브라우저가 보낸 대칭키를 복호화해서 얻는다. 이제 이 대칭키로 데이터를 암호화해서 주고 받는다.
기본 용어
- 웹 :
인터넷 상에 연결된 사용자들이 서로의 정보를 공유할 수 있는 무형의 네트워크 공간으로, 인터넷 상에서 텍스트나 그림, 소리, 영상 등의 정보를 하이퍼텍스트 방식으로 연결해서 제공하는 일종의 서비스다.
- 하이퍼텍스트 :
Hyper는 뛰어넘다, 초월하다 의 의미를 가진 단어로, 하이퍼텍스트는 텍스트를 뛰어넘는다는 의미이다. 일반적인 텍스트의 순차적 접근법을 뛰어넘는 비순차적 접근법을 말한다. 다른 페이지로 이동하거나 같은 페이지 내의 다른 데이터로 이동하는 것들도 모두 하이퍼텍스트의 개념이다.
- 프로토콜 :
공공의 데이터 교환 방법 및 순서에 대해 정의한 의사소통 규약
- TCP/IP :
데이터가 의도된 목적지에 닿을 수 있도록 보장하는 통신 규약으로 TCP와 IP 두 가지 프로토콜로 구성되어 있다. 현재 수많은 프로그램들이 인터넷으로 통신하는 데 있어 가장 기반이 되는 프로토콜이다.
- TCP(Transimission Control Protocol) :
두 호스트가 교환하는 데이터와 승인 메시지의 형식을 정의해서 서버와 클라이언트 간 데이터를 신뢰성있게 전달하기 위해 만들어진 규약이다. 데이터를 전달하는 과정에서 순서 등이 의도와 다르게 뒤바뀌거나 손실이 되어 전달되는 것을 방지하기 위해 데이터 패킷에 일련의 번호를 부여해서 데이터 손실을 찾아 교정하고, 순서를 재조합해서 클라이언트에게 전달한다.
- IP(Internet Protocol) :
컴퓨터와 컴퓨터 간 데이터 전송을 위해서는 컴퓨터의 주소가 필요한데, IP가 4바이트로 이루어진 컴퓨터의 주소이며, 192.168.9.255와 같이 3개의 마침표로 나누어진 숫자로 표시된다. IP는 TCP와는 달리 데이터의 재조합이나 손실 여부를 확인할 수 없고 단지 데이터를 전달하는 역할만 담당한다. 참고로, ip주소는 mac 주소와 달리 하드웨어 고유의 식별번호가 아니라, 임시적으로 통신사한테 다르게 받는 주소라서 바뀔 수 있다.
- Web Server
클라이언트의 request를 받아 정적인 컨텐츠(html,css,js)를 response하는 서버 (Apache, Nginx 등)
- WAS(Web Application Server)
클라이언트의 request를 받아 DB 조회나 어떤 로직을 처리해야 하는 동적인 컨텐츠를 response하는 서버 (Tomcat 등)
- Web Server와 WAS의 차이
어떤 타입의 컨텐츠를 제공하느냐의 문제로, 동적 컨텐츠이거나 정적 컨텐츠를 제공한다.
하지만 대부분의 WAS가 정적컨텐츠까지 제공하기 때문에 Web Server없이 WAS를 사용한다.
- WAS만 있어도 되는데 왜 굳이 WAS를 Web Server랑 같이 쓰는가?
WAS가 해야할 일의 무담을 줄이기 위해서 Web Server는 정적인 문서만 처리하게 하고 WAS는 어플리케이션의 로직만 수행하도록 기능을 분배하기 위함이다.
- MAC 주소란?
컴퓨터 간 데이터를 전송하기 위해 있는 컴퓨터의 물리적 주소.
절대 변하지 않는 그 기계의 고유 주소가 필요한데 그게 맥주소다.
- IP주소와 MAC 주소에 대해 설명하라
IP는 내가 미국에 있는 A 주소로 편지를 보낼게! 즉, 시작점과 끝점에 해당하는 주소고, MAC 주소는 바로 옆에 나와 물리적으로 연결되어 있는 노드와 통신할 때 사용되는 주소다. 시작점과 끝점에 가기 위해서는 사이사이 노드들을 거쳐 데이터가 전달되어야 하니까, IP 주소는 사실상 MAC 주소 간의 통신인 것이다. MAC 주소는 데이터링크 계층에서 사용되고, IP 주소는 네트워크 계층에서 사용되는데, 데이터 링크 계층이 문제 없이 동작해야 (이웃 노드들끼리의 통신이 되어야, 데이터링크 계층의 역할) 멀리 있는 노드에게도 통신이 가능해진다. (네트워크 계층 역할)
'Tech Interview' 카테고리의 다른 글
[직무인터뷰] JPA 이야기 (1) | 2021.06.07 |
---|---|
[직무인터뷰] Spring과 DB 이야기 - 2편 (0) | 2021.06.06 |
[직무인터뷰] Spring과 DB 이야기 - 1편 (2) | 2021.06.05 |
[직무인터뷰] JAVA 이야기 - 2편 (0) | 2021.05.19 |
[직무인터뷰] JAVA 이야기 - 1편 (4) | 2021.05.19 |