웹 서버

덤프버전 :

분류

1. 개요
2. 원리
3. 웹 서버의 특징
4. 보안
4.1. 암호화
4.2. 웹 서버의 보안 취약점
5. 웹 서버의 종류
6. 애플리케이션 서버
6.1. 웹 애플리케이션 서버 (Java)
7. 관련 통신 프로토콜
8. 관련 문서



1. 개요[편집]


하드웨어적 서버에 접속한 사용자에게 웹 서비스를 제공하기 위하여 사용되는 소프트웨어 서버의 한 종류. 이 글을 보는 당신이 지금 접속했던 서버.[1] 지금 당신이 보고 있는 위키가 굴러가기 위해 반드시 필요한 것.


2. 원리[편집]


HTTP을 이용하여 인터넷 브라우저와 통신하며, http 통신의 경우 일반적으로 80번 포트를, https 통신의 경우 일반적으로 443번 포트를 사용한다.

HTTP 자체가 TCP를 사용하나, UDP 프로토콜 또한 사용한다. 대표적인 예시로 실시간 동영상 시청[2] 같은 많은 패킷을 주고 받을때에 사용한다.


3. 웹 서버의 특징[편집]


일반적인 서버와는 달리 사용도가 높은 웹 서버의 경우, 적게는 수십, 많게는 수만의 요청을 받는 경우가 대부분이다.

HTTP의 특성상 데이터 전송을 종료하면 통신을 끊으며, 파일 전송, 동영상 시청과 같은 대량의 데이터를 송수신 하는 경우는 따로 서버를 구현하는 경우가 대부분이다.

페이스북이나 imgur 같이 데이터를 대용량으로 저장하는 서버는 웹 서버는 반드시 데이터베이스가 필요하다. 하지만 요즘은 인터넷의 발달로 데이터베이스가 없는 서버를 찾아보는게 더 어려워졌다.

다만 파일 전송의 경우는 FTP를 주로 사용하며[3][4], 실시간 동영상 시청UDP를 주로 사용한다.


4. 보안[편집]


웹 서버는 크래커주 공격 대상이다.

웹 서버는 기본적인 권한에 모두 같은 서비스를 제공한다, 많은 봇PC을 만들어 DDoS 공격에 써먹거나 XSS, CSRF, DB 크래킹 등을 통해 개인정보를 탈취하기에 가장 적합한 서버형태가 바로 웹 서버이다.


4.1. 암호화[편집]


웹 서버는 주로 SSL를 이용하여 암호화 하며, SSL 항목에서 볼수 있듯, 검증된 사이트에게만 인증서를 내어준다.

초보 웹 프로그래머가 웹 페이지를 불러오는 과정을 https를, 동영상을 불러오는 과정을 http로 하는 케이스가 심심찮게 보이는데, 이렇게 프로그래밍을 해버리면 브라우저에서 보안 경고를 내뱉는다.[5]

여담으로 나무위키TLS 1.3, AES_128_GCM 암호화와 ECDHE_ECDSA 키교환 매커니즘을 사용한다. 대부분의 요즘 사이트들은 HTTP/3가 적용되어 빠른 접속이 가능하다.


4.2. 웹 서버의 보안 취약점[편집]


  • OpenSSL하트블리드 취약점[6]
  • 유닉스 계열 OS의 bash 셸의 셸쇼크 취약점[7]
  • HTMLXSS 취약점
  • XSS 취약점 공격의 파생형인 CSRF
  • HTTP 메소드 취약점
  • 리다이렉트 취약점
  • SQL injection
  • 디렉토리 순회 공격(Directory traversal attack)


5. 웹 서버의 종류[편집]




6. 애플리케이션 서버[편집]


웹 환경을 통해 애플리케이션으로서 동작하는 서버. 일반적으로 웹 서버는 HTTP 요청과 파일을 주고받는 역할인 반면, 애플리케이션 서버는 복잡한 연산을 처리하며 데이터베이스나 외부 서비스와 상호작용하면서 비즈니스 로직을 처리한다. 즉 웹 페이지를 매개로 하여 사용할 수 있는 응용 프로그램이다.

원래 웹 서버와 애플리케이션 서버는 따로 구분하지 않았으나, 웹 사이트가 점차 다양하고 복잡한 작업을 맡게 되면서 두 가지를 구분하게 되었다. 웹 서버는 클라이언트(웹 브라우저)가 보낸 HTTP 요청을 받아 디스크에 보관된 HTML, CSS, 자바스크립트 등의 파일을 송수신하는 역할을 주로 맡지만, 애플리케이션 서버는 요청에 따라 데이터베이스를 조회하거나, 데이터를 가공하거나, 다른 프로그램에 추가적인 요청을 보내거나, 입력값을 바탕으로 결과값을 계산하는 등의 복잡한 작업을 맡는다. 다만 이러한 기능들이 완전하게 분리된 것은 아니어서, 대부분의 애플리케이션 서버는 디스크에 보관된 정적 파일을 송신할 수 있다.

애플리케이션 서버는 디스크에 저장된 HTML 파일을 그대로 보내주는 대신 데이터베이스나 외부 서비스에서 가져온 데이터를 가공해 즉석에서 웹 페이지를 만들어낸다. 따라서 같은 주소에 접속해도 사용자나 환경에 따라 다른 형태의 페이지를 보여줄 수 있다.

좁은 의미에서, 애플리케이션 서버는 프로그래밍 언어를 사용해 개발한 웹 애플리케이션, 또는 이를 실행하고 관리하는 소프트웨어를 가리킨다. Java, JavaScript, PHP, Python, Ruby 등의 다양한 언어로 애플리케이션 서버를 만들 수 있으며, 그 중에서도 PHP나 JSP와 같이 처음부터 웹 애플리케이션 개발을 목적으로 만들어진 언어도 있다. 주로 실행 파일의 형태로 만들어지는 데스크톱 소프트웨어에 비해 스크립트 언어가 비교적 잘나가는 분야인데, 이는 사용자의 PC 성능에 절대적인 영향을 받는 데스크톱 프로그램과 달리 웹 브라우저만 굴릴 수 있다면 누구나 애플리케이션 서버를 이용할 수 있기 때문이다. 단, 하드웨어와 스크립트 언어의 성능이 크게 발전하면서 이러한 구분은 흐릿해지고 있다.


6.1. 웹 애플리케이션 서버 (Java)[편집]


웹 애플리케이션 서버(Web Application Server)는 J2EE(Java Enterprise Edition)의 스펙을 구현하여, 서블릿(Servlet)이나 JSP로 작성된 애플리케이션을 실행하는 소프트웨어이다. Tomcat은 J2EE의 스펙을 모두 구현하고 있지는 않으므로[8] 웹 애플리케이션 서버라고 할 수는 없으나, 기본적인 웹 서버 및 서블릿 컨테이너로서의 기능은 모두 수행한다. 따라서 '웹 컨테이너' 정도가 Tomcat을 분류하는 가장 좋은 용어가 될 것이다.

  • JEUS[9]
  • WebLogic


7. 관련 통신 프로토콜[편집]




8. 관련 문서[편집]



파일:크리에이티브 커먼즈 라이선스__CC.png 이 문서의 내용 중 전체 또는 일부는 2023-12-11 12:48:18에 나무위키 웹 서버 문서에서 가져왔습니다.

[1] 왜 과거형인지 궁금하다면 HTTP 문서를 보거나 아래를 참고하자.[2] 인간은 1920*1080 같은 해상도에 LED 한두개가 꺼진것을 인식 못한다.[3] 압축파일 같은걸 UDP로 전송해서 손실이 발생하면 그 압축 파일은 못쓴다고 보는것이 일반적이다.[4] 보안이 중요한 서버의 경우 SFTP, FTPS를 쓴다.[5] 경고를 내뱉어도 고치다가 결국은 지쳐서 틀렸어 이제 꿈이고 희망이고 없어 상태가 되어버리는게 다반사다.[6] 만들어진지 2년 동안 발견되지 않은 심각한 버그.[7] 야후는 공격당한 서버 3곳을 아예 분리시켜버렸다.[8] EJB 등 몇 가지 기능은 빠져 있다.[9] 위의 Zeus와는 다르다. Zeus는 영국의 제우스 테크놀로지가 개발한 웹 서버이고, JEUS는 한국의 티맥스소프트가 개발한 웹 애플리케이션 서버이다.