[네트워크] 웹 접속과정, 쿠키, 세션 질문, 답변

 

 

 

 

 

[www.google.com](http://www.google.com) 을 브라우저에 입력하고 엔터를 쳤을 때, 네트워크상 어떤 일이 일어나는지 설명해 주세요.

• 브라우저는 입력한 URL을 해석하여 호스트 이름인 www.google.com을 추출합니다.
• 브라우저는 이 호스트 이름을 IP 주소로 변환해야 합니다. 이를 위해 브라우저는 운영체제 내의 DNS 캐시를 먼저 확인합니다. DNS 캐시에 해당 호스트 이름의 IP 주소가 캐싱되어 있으면, 브라우저는 이를 사용하여 서버와 통신합니다. 그렇지 않은 경우, 브라우저는 DNS 서버에 호스트 이름을 질의하여 IP 주소를 얻습니다.
• 브라우저는 얻은 IP 주소를 사용하여 HTTP 요청 메시지를 생성합니다. 이 메시지에는 호스트 이름 대신 IP 주소가 포함되어 있습니다.
• 브라우저는 생성한 HTTP 요청 메시지를 TCP/IP 프로토콜을 사용하여 인터넷을 통해 서버로 전송합니다.
• 서버는 요청 메시지를 수신하고, 요청에 대한 응답을 생성합니다.
• 서버는 생성한 응답 메시지를 TCP/IP 프로토콜을 사용하여 인터넷을 통해 브라우저로 전송합니다.
• 브라우저는 수신한 응답 메시지를 해석하고, HTML, CSS, JavaScript 등의 리소스를 처리하여 화면에 표시합니다.

 

https://velog.io/@eassy/www.google.com%EC%9D%84-%EC%A3%BC%EC%86%8C%EC%B0%BD%EC%97%90%EC%84%9C-%EC%9E%85%EB%A0%A5%ED%95%98%EB%A9%B4-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EC%9D%BC

DNS 쿼리를 통해 얻어진 IP는 어디를 가리키고 있는가?

• 해당 도메인의 호스트(서버)를 가리킵니다. www.google.com 도메인의 IP 주소를 DNS 쿼리를 통해 얻어냈다면, 해당 IP 주소는 Google 서버를 가리키게 됩니다.

Web Server와 Web Application Server의 차이에 대해 설명해 주세요.

• 가장 큰 차이는 웹서버는 정적 컨텐츠를 제공하고 WAS는 동적 컨텐츠를 제공한다는 점입니다. 
• 정적 컨텐츠란 누가, 언제 요청하든 똑같은 정보를 제공해 주는 컨텐츠입니다. 쿠팡 사이트의 카테고리탭이나 배너들이 이에 해당하며 HTML, CSS, JavaScript 로 이미 만들어진 결과물을 사용자에게 보여주는 것입니다. 
• 동적 컨텐츠는 누가, 언제 요청했는지에 따라 달라지는 정보입니다. 내정보에서 구매내역, 장바구니 등에 해당합니다. 이를 주기 위해서 DB에서 정보를 얻습니다. 
• 순서를 보자면 Client - 웹서버 - WAS - DB 순입니다. 클라이언트가 정적컨텐츠를 요청하면 웹서버에서 바로 제공하고 동적컨텐츠를 요청하면 WAS까지 와서 데이터를 제공해주는 프로세스입니다. 
• 사실 WAS가 웹서버 역할도 할 수 있어서 웹서버 없이도 서비스는 가능합니다. 그럼에도 두가지를 모두 두는 이유가 있습니다.
• 물리적 분리로 보안 강화 : WAS는 DB와 직접 연결되어 있는데 DB에는 개인정보는 민감한 데이터들이 들어있습니다. 그래서 앞에 웹서버를 둠으로써 보안이 뚫려도 한단계 더 있기 때문에 조금 더 유리합니다.
• 웹서버를 두면 여러 WAS를 연결할 수 있습니다. JAVA서버, C서버, PHP서버 등 종류가 다른 서버를 하나의 웹서버에 연결하여 구성할 수 있습니다.
• WAS에서 장애가 나도 웹서버의 정적컨텐츠는 정상적으로 제공하기 때문에 서비스 이용자에게 오류상황을 인지하지 못하게 하고 복구할 수 있는 시간을 벌 수 있습니다.

URI, URL, URN의 차이점은 무엇인가요?

• URI : 인터넷에서 사용되는 모든 리소스(문서, 이미지, 비디오 등)를 식별하기 위한 문자열입니다. URL과 URN을 포함합니다.
•  
• URL : 인터넷에서 특정 리소스의 위치를 나타내는 문자열입니다. 이 위치는 프로토콜, 호스트명, 포트번호, 리소스 경로 등으로 구성됩니다. 
• 예를 들어, "http://www.example.com/index.html"은 http 프로토콜을 사용하는 www.example.com 서버의 index.html 파일을 나타냅니다.
•  
• URN
• 이름으로 리소스를 특정하는 URI이다.
• http와 같은 프로토콜을 제외하고 리소스의 name을 가리키는데 사용된다.
• URN에는 리소스 접근방법과, 웹 상의 위치가 표기되지 않는다.
• 리소스 자체에 부여된 영구적이고 유일한 이름이고 변하지 않는다.
• 실제 자원을 찾기 위해서는 URN을 URL로 변환하여 이용한다.
• ‘감옥으로부터 사색’ 이라는 책의 URN(고유 이름) : urn:isbn:9788971771060 
• isbn은 국제표준도서번호
• 어떤 논문의 URN : urn:doi:10.1162/153244303322533223
• DOI (Digital Object Identifier)는 학술 논문, 책, 뉴스 기사, 영상 등 디지털 콘텐츠를 식별하기 위한 국제 표준 식별자

 

https://hanamon.kr/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EA%B8%B0%EB%B3%B8-url-uri-urn-%EC%B0%A8%EC%9D%B4%EC%A0%90/

—----------------------------------------------------------------------------------------------------------

Cookie & Session

쿠키와 세션의 차이는 무엇인가요?

• 가장 큰 차이점은 사용자의 정보가 저장되는 위치입니다. 때문에 쿠키는 서버의 자원을 전혀 사용하지 않으며, 세션은 서버의 자원을 사용합니다.
• 보안 면에서 세션이 더 우수하며, 요청 속도는 쿠키가 세션보다 더 빠릅니다. 그 이유는 세션은 서버의 처리가 필요하기 때문입니다.
• 보안 : 쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약하지만 세션은 쿠키를 이용해서 sessionid 만 저장하고 그것으로 구분해서 서버에서 처리하기 때문에 비교적 보안성이 좋습니다.
• 라이프 사이클 : 쿠키도 만료시간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 계속해서 정보가 남아 있을 수 있다. 또한 만료기간을 넉넉하게 잡아두면 쿠키삭제를 할 때 까지 유지될 수도 있습니다.
• 반면에 세션도 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제됩니다. 예를 들어, 크롬에서 다른 탭을 사용해도 세션을 공유됩니다. 다른 브라우저를 사용하게 되면 다른 세션을 사용할 수 있습니다.
• 속도 : 쿠키에 정보가 있기 때문에 서버에 요청시 속도가 빠르고 세션은 정보가 서버에 있기 때문에 처리가 요구되어 비교적 느린 속도를 가집니다.

세션 방식의 로그인 방식

• 사용자가 로그인 페이지에 접근합니다.
• 사용자가 입력한 로그인 정보(일반적으로 사용자 이름과 비밀번호)가 서버에 전송됩니다.
• 서버는 이 정보를 확인하고, 사용자가 인증되었다는 것을 확인하면, 사용자에 대한 새로운 세션 ID를 생성합니다.
• 서버는 세션 ID를 쿠키로 만들어 사용자에게 전송합니다.
• 사용자의 브라우저는 이 쿠키를 저장하고, 이후에 해당 웹 사이트에 접속할 때마다 이 쿠키를 서버에 전송합니다.
• 서버는 세션 ID를 확인하여 사용자를 인증합니다.
• 사용자가 로그아웃하거나 일정 기간이 지나면, 세션은 종료됩니다.

HTTP의 특성인 Stateless에 대해 설명해 주세요.

• 통신이 끝나면 상태를 유지하지 않는 특징
• 연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다.

https://interconnection.tistory.com/74

HTTP Stateless → 세션이 맞는 방식인가?

Stateless의 의미를 살펴보면, 세션은 적절하지 않은 인증 방법 아닌가요?

• Stateless 는 HTTP의 특성일 뿐이다. 룰이 아니다. 그러한 특성을 보완하기 위해 쿠키와 세션을 사용하는 것인데 Stateless 니까 세션은 적절한 방법이 아니다? 라는 질문은 애초에 잘못된 것이라고 생각한다.

규모가 커져 서버가 여러 개가 된다면, 세션을 어떻게 관리할 수 있을까요?

• 로드 밸런서 : 여러 개의 서버가 있을 경우, 로드 밸런서를 사용하여 서버 간의 부하를 분산시킵니다. 이를 통해 세션 처리 능력을 높일 수 있습니다.
• 세션 클러스터링 : 서버 간의 세션 정보를 공유하기 위해, 세션 클러스터링을 사용합니다. 세션 클러스터링은 여러 개의 서버가 동일한 세션 데이터를 공유하는 방식으로, 한 서버에 문제가 생기면 다른 서버에서 세션정보를 사용합니다.
• 분산 캐싱 : 세션 데이터를 분산 캐싱하여, 세션 데이터에 대한 처리 성능을 높입니다. 캐싱된 데이터는 메모리나 디스크 등의 스토리지에 저장됩니다.
• 공유 스토리지 : 여러 서버가 공유하는 스토리지를 사용하여 세션 정보를 관리할 수 있습니다. 공유 스토리지는 네트워크 파일 시스템, 분산 데이터베이스, 메시지 큐 등의 기술을 사용할 수 있습니다.

Session 인증 방식과 Token 인증 방식의 차이점

• 저장 위치 : Session은 서버 측에 정보를 저장하고, Token은 클라이언트 측에 정보를 저장합니다.
• 유지 기간 : Session은 일정 기간 유지되고, 만료되면 재인증이 필요합니다. Token은 만료 기간이 있으며, 만료되면 재발급이 필요합니다.
• 확장성 : Session은 서버 측에서 관리되기 때문에, 서버의 부하를 높일 수 있습니다. Token은 클라이언트 측에서 관리되기 때문에, 서버 부하를 낮출 수 있습니다.
• 보안성 : Session은 보안성이 조금 더 높고, Token은 상대적으로 낮습니다.