태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.
보이기/숨기기 가능합니다^^
분류 전체보기 (264)
이벤트정보 (14)
서버호스팅 (32)
웹호스팅 (8)
가격 및 평가 (2)
도메인 (17)
호스팅 상식 (10)
기타호스팅 (7)
서버 정보 (36)
IDC (8)
가격비교정보 (3)
웹 기획 (1)
웹 제작 (15)
웹 마케팅 (6)
리눅스정보 (15)
윈도우서버 (16)
추천서적 (0)
솔루션가이드 (8)
자료실 (7)
호스팅용어 (6)
문서자료실 (0)
보안 (25)
기타 활용팁 (8)
인터넷기초자료 (2)
IT 이야기 (4)
WinSCP (3)
클라우드컴퓨팅 (4)

보이기/숨기기 가능합니다^^

'호스팅 상식'에 해당되는 글 10건
클라우드 서버와 서버호스팅의 비교
호스팅 상식 | 2016. 10. 11. 12:31


인프라 클라우드(IaaS)로 가장 많이 사용하는 것이 클라우드 호스팅입니다. 호스팅이란 서버를 IDC에 맡긴다라는 개념으로 이해하면 됩니다.

가상화 기술을 통해 물리적인 서버를 분할하여 한대의 서버를 여러대인 것 처럼 사용할 수 있는 것이 VPS(가상서버)라고 하며, 가상서버를 더 자동화하고 체계화한 것이 클라우드 서버입니다.



서버를 단순하게 구성하면 가상서버와 클라우드서버의 차이는 크게 없습니다.

전통적인 방식의 서버호스팅은 물리서버 1대에 1개의 OS가 구동되어 서비스가 되는 방식이기 때문에 기존의 엔지니어들이 접근하는 방식으로 사용할 수 있습니다.

서버에 IP를 할당하고, OS를 설치하여, 관리자계정으로 들어가 보안설정을 한 후 필요한 SW를 인스톨하여 바로 사용했습니다.

시스템 구성이나 확장은 서버 단위나 모듈 단위로 붙여 나가는 방식으로 진행했습니다.

예를 들면, 웹서버 1대에서 2대로 확장하면서 L4스위치를 붙여 로드밸런싱으로하고, DB서버를 추가하고, DB서버 이중화를 하고, 방화벽이나 IPS를 갖다 붙이고 하는 방식으로 시스템을 구성해 나갔습니다.

그러나 클라우드 서버의 경우는 미리 어느 정도의 프레임을 갖춰 놓고 확장이 될 수 있는 여러가지 요소들이 확장될 수 있다는 전제의 기능들이 눈에 보입니다. 별것 아니지만 신경이 쓰이고, 다양한 기능들을 모른다는 것이 나중에 문제가 될 소지가 있을 것처럼 염려되기도 합니다.

그래서 미리 사설네트워크를 설계하고 보안을 설계하고 서버를 설치하여 사용하게 됩니다. 물론 대형시스템을 설계하고 운영하는데는 편리합니다.(다만 비용이 나중에 기존 물리적인 장비로 구성하는 것보다 많이 들어갑니다.)


클라우드서버의 중요한 특징 중에 하나인데, 처음에는 비용이 저렴한 것 처럼보이지만 나중에는 더 많은 비용을 지불하게 됩니다.

작은 규모의 클라우드가 저렴한 것은 효율적으로 HW 자원을 사용하기 때문에 클라우드업체에서는 고객에게 저렴한 비용으로 제공하는 편입니다.

효율적으로 HW자원을 활용한다라는 점은 자체적으로 프라이빗 클라우드를 구축하면 비용이 절감된다라는 것과 같습니다.


다른 특징중에 하나는 장애처리 부분입니다.


서버호스팅이나 물리서버구성의 경우 시스템 설계자와 운영자가 거의 일치하여 장애 포인트를 찾기 쉽습니다. 그러나 클라우드 서버의 경우 전체적인 클라우드 시스템 설계자와 운영자가 있고, 이용자쪽에서 서비스를 운영하는 시스템 설계자와 운영자가 있습니다. 


클라우드 서버의 경우 장애 포인트를 찾기가 어려울 수 있으며, 운영자가 의도하지 않은 부분에 있어 발생하는 장애는 대처하기가 어렵다는 점이 문제입니다. 


잘 운영되던 시스템이 내부네트워크에서 갑자기 패킷로스가 발생할 경우, 기본의 호스팅 방식에서는 네트워크 장비와 케이블, OS등의 문제를 살펴볼 수 있지만, 클라우드의 경우 복잡한 문제해결 방식을 찾아야 하고, 클라우드 제공사 역시도 복잡한 시스템의 특성상 시니어엔지니어가 투입되어 해결방안을 찾아야 할 때가 많습니다.

위와 같은 문제점에 대비하여 클라우드 서버의 경우는 중복적으로 다른 리젼이나 타 시스템에 이중화를 해놓고 대비하여야 할 수 도 있습니다.


서버호스팅은 전통적인 방식입니다. 다음과 같은 이유로 인해 클라우드로라는 발전된 개념의 인프라 운영방식이 출현되었습니다.


- 유연하지 못한 확장성

- 컴퓨팅 자원 활용의 비효율성

- OS설치까지의 시간 소요

- 수작업을 통한 시스템 구성과 변경 


그러나 전통적인 서버호스팅과 클라우드의 선택은 기술의 진보를 채택할 것인가 기존의 익숙한 방식으로 일처리를 할 것이냐는 의사결정자의 선택일 수 밖에 없으며, 시대에 앞서가는 사람이 될 것인가? 여러가지 장점에도 불구하고 기존의 방식을 개선하여 이용할 것인가? 라는 선택속에서 비교를 하면 될것입니다.

기존의 서버호스팅 방식은 클라우드라는 새로운 흐름을 통해 또 다시 개선되어 가고 있습니다.

그래서 클라우드와 서버호스팅은 하이브리드라는 결합되어 서로 개선되는 방식으로변화되어 갈 것입니다.









Trackbacks 2 : Comments 0
위로
중국내 서버 사용을 위한 ICP에 대한 소개
호스팅 상식 | 2014. 10. 15. 13:54


중국내 서버를 통해 서비스를 하기 위해 반드시 필요한  ICP, 중요한 핵심내용을 Q&A식으로 정리하였습니다. ICP만들기는 그리 간단하지 않은데, ICP 없이 서비스 품질을 높여 서버를 사용할 수 있는 방안도 있습니다. 중국내 웹서비스 제공에 대한 여러가지 사항들을 정리하여 반드시 중국내 서버를 두어야 하지는도 잘 고민해 봐야 할것입니다. 


ICP라이센스는 무엇인가?


인터넷 컨텐츠 제공 사업자 라이센스(ICP)는 중국 정부에 의해서 발행되며, 웹사이트 책임이 있는 담당자와 담당조직을 구분하는 사이트/도메인에 대한 공식적인 등록입니다. ICP 번호를 얻는 데는 두가지 방법이 있습니다. 하나는 ICP 라이센스이고, 다른 하나는 ICP 파일리 처리입니다. ICP 라이센스 번호는 웹사이트 하단에 포함되어야 합니다.


ICP는 어떤 사업자에게 필요한가?


중국내에 서버로 부터 컨텐츠 서비스를 하기 원하는 모든 컨텐츠 제공사업자와 발행사업자는 ICP 라이센스가 필요합니다. 중국 정부는 중국내에서 모든 서비스 제공사업자에게 2009년 6월 30일까지 ICP를 등록하지 않는 컨텐츠 사업자는 서비스를 중단하라고 통보 했습니다.


ICP의 종류


중국법은 사업적인 웹사이트와 단순 정보를 제공하는 웹사이트의 구분을 두고 있습니다.

비상업적인 사이트가 비교적 단순한 ICP 파일처리만 요구되는데 반하여, 상업적인 사이트는 좀 더 복잡한 ICP 라이센스가 요구됩니다.


ICP라이센스를 등록하기 위해 필요한 것

중국내 적합한 절차로 법인을 설립해야 합니다.


ICP 파일처리에 필요한 내용

1. 회사명

2. 회사성격

3. 중국내 사무실 주소

4. 중국내 사업자등록번호

5. 법적 대표자 이름 , 전화번호

6. 본사 사무실 이름

7. IP주소 / 호스팅 회사명

8. URL 주소


ICP 없이 중국내 서비스를 할 수 있나?

중국 외부에 서버를 두면 ICP발급을 받지 않고 서비스를 할 수 있습니다.

다만, 속도문제가 발생하여 중국내 서버를 두는 것 보다 불리합니다.

그러나 SK브로드밴드 차이나호스팅 팩(http://www.skcdn.com/service/hostingpack.jsp)을 이용하면 속도의 문제는 극복할 수 있습니다.








Trackbacks 0 : Comments 0
위로
로드밸런싱의 적용 방식과 L4 임대 방식 이용 비용
호스팅 상식 | 2011. 6. 15. 11:25


L4 로드밸런싱은 하나로 돌아가는 웹서비스를 여러대의 서버로 분산함에도 사용자들은 하나처럼 보일 수 있게 하는 서비스입니다. 한대의 서버로 돌아가는 서버부하 문제, 접속자가 많아 속도가 저하되는 문제, 장애로 인해 서버가 다운되는 문제점을 해결할 수 있는 가장 좋은 해결방법입니다.



로드밸런싱은 DNS 라운드로빈, LVS, L4 등 3가지 방법으로 합니다.

DNS 라운드로빈

장점으로는 별도의 비용없이 네임서버에서 간단하게 설정만으로 구축이 가능하여 비용과 설치가 간단합니다.
그러나 서버의 상태를 체크하지 않기 때문에 서버가 장애가 나거나 부하가 발생해도 감지하지 못하고 기계적으로 이상이 있는 서버쪽에 연결을 보냅니다.

만일 DNS 라운드로 로빈을 사용하게 되면 계속 서버상태를 체크하여 이상이 있다면 DNS상에서 해당서버의 IP주소를 빨리 빼내는 것이 중요합니다. 이것만 빠르게 처리된다면 그리 나쁘지 않은 로드밸런싱 방법입니다.


LVS(Linux Virtual Server)

리눅스에 로드밸런싱이 가능한 소프트웨어를 설치하여 부하 분산을 처리하는 방법입니다. 공개소스기 때문에 별도 비용은 들어가지 않습니다. 그러나 LVS는 네트워크 이상에 대해 민감하게 반응 할 수도 있고, 장애에 대한 메세지가 친절하지 않아 장애에 대한 대처가 힘들어 별로 추천하지는 않습니다.
10대중 5~6대는 원인 모를 문제 때문에 가동을 중단하기도 합니다. 비용도 리눅스 서버를 구축해야 하기 때문에 저렴한 편도 아닙니다.


L4 스위치 방식
사용자가 웹서비스를 접속하면 네트워크 쪽에서 L4스위치로 연결하고 L4스위치에서 리얼서버의 상태를 파악해 정상적으로 가동되는 서버로 부하를 분산시켜주는 방식입니다.

안정적이며 가장 이상적으로 부하를 분산시켜줍니다. 다만 단점이 있다면 아직도 L4스위치의 비용이 고가라서 소규모 서비스에는 도입을 주저하는 경우가 많습니다. 임대방식으로 서비스가 되고 있는데 누리호스팅에서 월 20만원 정도 합니다. 서버 1대 임대 비용정도라서 저렴하게 이용할 수 있는 방법이 될 수 있습니다.




Trackbacks 0 : Comments 0
위로
IPv4 주소고갈과 2011년 IPv6 시대
호스팅 상식 | 2011. 2. 1. 17:52



2011년 2월 4일 부터 IANA로 부터 전세계의 IPV4할당이 중지됩니다.
IANA는 Internet Assinged Numbers Autority 의 약자이며
인터넷 IP주소 할당 기관으로 전세계의 IP주소와 최상위 도메인을 관리하는 기관입니다.



IPV4는 0.0.0.0 ~ 255.255.255.255 까지의 숫자 조합으로 구성된 32비트 주소관리 체계입니다.

국내에서는 KISA에서 할당을 받아 주소를 ISP에 배분합니다.

스마트폰의 활성화와 가상화로 작년에 많은 IPV4 주소를 사용했던 영향으로
예상했던 것보다는 더 빨리 IPV4 주소가 고갈되고 있습니다.

IPV4는 4,294,967,296개의 주소를 사용할 수 있습니다.


국내에 이미 할당 받아놓은 주소가 있어 당분간은 문제가 없겠지만 
올해 하반기 중으로 주소 고갈 문제가 나올 가능성이 큽니다.




문제해결방식은 IPV6의 사용입니다. 

현재까지 네트워크 장비들이 거의 IPV6를 지원하고 있기 때문에 서버단의 큰 혼란은 없겠지만 클라이언트단에서는 아직도 IPV6와 호환이 되지 않는 장비와 SW가 많이 있기 때문에 IPV6와 기존의 어플리케이션과 장비의  호환문제가 발생할 소지가 큽니다. 

미리 IT담당자들은 사전에 대응을 하고 있어야합니다.



Trackbacks 0 : Comments 2
위로
From. Favicon of http://nightworm.tistory.com/ BlogIcon 밤벌레 2011.02.01 20:18
PERMALINKDELETE/MODIFYREPLY
내용 잘읽었습니다..6월로 알고 있었는데
2011년 2월 4일부로 중지 되는게 확실한가요?
조기 전환이 되는건가용..
From. Favicon of https://www.allhost.co.kr BlogIcon 올호스트 URECA 2011.02.21 16:45 신고
PERMALINKDELETE/MODIFY
kisa에 공지된 내용입니다.
홈페이지가 열리지 않습니다. 해결 방법
호스팅 상식 | 2009. 3. 12. 17:09


1. 도메인 주소의 만료기간이 지났는지 확인해 본다. 정말 많은 경우 도메인 만료기간이 지난 줄 모르고 서버나 프로그래밍의 문제에서 홈페이지가 안열리는 문제를 해결하려고 한다.

2. 하드디스크의 용량을 체크해 본다. 특히 로그파일의 증가로 디스크가 Full이 난 경우 갑자기 홈페이지가 안들어 가진다.

※ 로그파일 삭제
[root@www]# cat /dev/null > access_log.1

3. 동시접속자의 한계를 넘어섰다. 아파치의 경우 netstat -nat | more 로 http 프로세수 갯수를 확인해 본다.

4. DB 접속 계정에 뭔가의 문제가 있다.(패스워드 기간 만료등을 체크해 본다.)

5. 해킹으로 인해 index 파일의 변조가 발생했다. index 파일의 변경일자를 확인해 보고, 소스상에 이상한 부분이 있으면 제거한다.

6. 기타 확인할 수 없는 문제 -> 리부팅

7. 리부팅을 처리할 수 없는 문제 -> OS 재설치



Trackbacks 0 : Comments 0
위로
동시접속자 수 1000명 이상을 위한 추천 사양
호스팅 상식 | 2009. 2. 19. 11:23



서버를 운영할 때 가장 궁금해 하는 것은 이 서버가 과연 얼마나 많은 동시접속자가 발생할까 하는 문제입니다.

이 부분은 정확히 계산을 통해 산출될 수 있는 사항은 아닙니다.

DB Connection이 얼마나 필요한지? 쿼리 속도는 평균 얼마나 나오는지? 각 페이지의 데이터가 얼마인지? 사용자의 이용빈도수는 어떤지? 등에 대한 복합적인 변수가 모두 고려되어야 하니까요.

대략 켄츠필드급 1CPU /2G램 에서는 500명 정도를 최대치로 생각하시면 되고, 이 보다 더 많은 동시접속자가 필요하다면 2 Way 급의 서버를 사용하면 됩니다.

아래 사양이라면 1000~ 1500까지 동시접속자를 가질 수 있는 사양이 될겁니다.

Xeon 5405 듀얼 CPU 장착
메모리 : 8G (FBDIMM PC2-5300) - 1G 짜리 8개를 장착하는 것이 유리한 듯합니다.
OS : 64 Bit
HDD : 73G SAS 3개이상(레이드 5)

단 DB쪽 쿼리가 많이 복잡하지 않아야 합니다. 서버의 동시접속자수는 DB Connection 수와 같다고 보시면 됩니다.
어짜피 웹페이지쪽은 저사양의 서버도 동접 1000명은 무난히 커버하니까요.
 
위의 사양으로 서버를 구성하시려면 대략 400만원~500만원 정도의 서버 구입비용이 발생합니다.
 
앞으로 서버의 CPU는 매년 2배씩 증가한다고 하면, 내년쯤이면 300만원 내외에서 이런 구성을 할 수 있을 겁니다.


Trackbacks 0 : Comments 2
위로
From. 궁금이~ 2009.07.02 19:13
PERMALINKDELETE/MODIFYREPLY
찾다찾다왔습니다.
지금 글쓰신 내용을 참조 할수 있는 문건이나 자료가 있을까요?이부분이 너무나 궁금 함니다.
From. 2016년 2016.04.22 09:32
PERMALINKDELETE/MODIFYREPLY
저도 찾다찾다 왔습니다
사양을 어떻게 계산할수있는건가요..?
해외 각국에서 내 서버의 ping 값은?
호스팅 상식 | 2008. 12. 13. 14:31


해외 서비스용이나 해외 접속이 있는 서버를 이용하기 위해서는 각 IDC의 해외 회선 상태를 파악하는 것이 우선 순위입니다.

그러나 한국에 있으면서 해외에서 내 서버나 호스팅회사 서버로 ping을 날리기는 어렵습니다.

이러한 세계각국의 ping 상태를 확인할 수 있는 사이트가 있는데, http://www.just-ping.com/ 입니다.

접속하여 도메인 주소 또는 IP주소를 입력하면 세계 각국 각 도시마다 접속되는 ping 값을 보여주는 서비스입니다.

아래 그림은 예로 http://www.yahoo.co.kr/ 을 입력한 결과입니다. 간단히 사이트만 접속해서 첫페이지에 서 ping 값을 확인할 수 있다. 네트웍 경로를 알아보는 tracert 서비스도 함께 제공하고 있습니다.

사용자 삽입 이미지


Trackbacks 0 : Comments 0
위로
HTTP 에러코드와 상태 코드 정리
호스팅 상식 | 2008. 3. 18. 12:39


상태코드 메세지 설명
100 Continue
클라이언트로부터 일부 요청을 받았으니 나머지 요청 정보를 계속 보내 주시오.
101 Switching Protocols
서버는 클라이언트의 요청대로 Upgrade 헤더를 따라 다른 프로토콜로 바꿀 것임.
200 Ok
모든 것이 정상적임. GET이나 POST 요청 뒤에 문서가 온다. 이것은 서블릿의 기본 상태다. setStatus를 사용하지 않으면 이 상태코드를 얻게 된다.
201 Created
서버에서 문서를 만들었음. Location 헤더는 그 URL을 가리킨다.
202 Accepted
요청이 수행되었지만 처리는 끝나지 않았음.
203 Non-Authoritative Information
문서는 정상적으로 반환되었지만 복사본이 사용되었으므로 응답 헤더중 일부가 정확하지 않을 수 도 있음.
204 No Content
새 문서 없음. 브라우저는 이전 문서를 계속 보여줘야 한다. 이것은 사용자가 페이지를 주기적으로 리로드를 하던 중 이전 페이지가 이미 만료되었을 때 사용할 수 있다. 하지만 Refresh 응답 헤더나 같은 헤더를 사용 해서 페이지를 자동으로 리로드 시켰을 때는 동작하지 않는다. 왜냐하면 이 상태 코드를 반환하면 추후의 리로딩이 멈추기 때문이다. 하지 만 자바 스크립트로 리로드하게 해 주는 것은 작동한다.
205 Reset Content
새 문서 없음. 하지만 브라우저는 문서 창을 리셋해야 한다. 브라우저가 CGI 폼 필드를 전부 지우도록 할 때 사용 된다.
206 Partial Content
클라이언트가 Range 헤더와 함께 요청의 일부분을 보냈고 서버는 이를 수행했음.
300 Multiple Choices
요청된 문서가 여러 군데서 발견되었음. 이 때 서버는 해당하는 모든 문서들을 나열할 것이다. 만약 서버가 선호하는 선택이 있으면 Location 응답 헤더에 나열해야 한다.
301 Moved Permanently
요청된 문서는 어딘가에 있고 그 문서에 대한 URL은 Location 응답 헤더에 주어졌음. 브라우저는 자동적으로 새 URL의 링크를 따라가야 한다.
302 Found
301과 비슷하지만 새 URL은 임시 저장 장소로 해석된다. 이 메시지는 HTTP 1.0에서는 ‘Moved Temporarily'였다. 그리고 HttpServletResponse의 상수는 SC_FOUND가 아니라 SC_MOVED_TEMPORARILY다. 이것은 매우 유용한 헤더인데 이 헤더를 통해 브라우저가 자동적으로 새 URL의 링크를 따라가기 때문이다. 이 상태 코드는 아주 유용하기 때문에 이 상태 코드를 위해 sendRedirect 라는 특별한 메소드가 있다. response.sendRedirect(url)을 사용하는 것은 response.setStatus(response.SC_MOVED_TEMPORARILY)과 response.setHeader("Location", url)를 쓰는 것에 비해 몇 가지 장점이 있다. 첫째, 더 쉽게 사용할 수 있다. 둘째, sendRedirect을 써서 서블릿이 그 링크를 포함한 페이지를 자동으로 만들어 준다(자동으로 redirect를 따라갈 수 없는 오래 된 브라우저에서도 볼 수 있게 해 준다). 마지막으로, sendRedirect에서는 상대 URL이 절대 URL로 해석되기 때문에 상대 URL도 다룰 수 있다. 이 상태 코드는 종종 301번과 혼용된다. 예를 들어 (맨 마지막에 ‘/'이 빠짐)과 같이 오류가 있는 요청에 대해 어떤 서버는 301을 어떤 서버는 302 를 보낸다. 기술적으로 브라우저는 원 요청이 GET이었다면 자동적으로 리다이렉션을 따라 가도록 되어 있다. 더 자세한 사항은 307 헤더를 보세요.
303 See Other
301/302과 같지만 원래 요청이 POST였을 경우 리다이렉트 되는 문서(Location 헤더에 주어졌다) GET을 통해 받아야 한다.
304 Not Modified
클라이언트의 캐시에 이 문서가 저장되었고 선택적인 요청에 의해 수행됨(보통 지정된 날짜보다 더 나중의 문서만을 보여주도록 하는 If-Modified-Since 헤더의 경우). 서버는 클라이언트에게 캐시에 저장된 이전 문서를 계속 사용해야 한다고 말할 것이다.
305 Use Proxy
요청된 문서는 Location 헤더에 나열된 프록시를 통해 추출되어야 함.
307 Temporary Redirect
Temporary Redirect 이것은 302 ("Found" 또는 "Temporarily Moved")와 같다. 많은 브라우저에서 메시지가 POST일 때 원래는 303 응답의 POST 요청의 리다이렉션을 따라 가야 함에도 불구하고 302의 응답을 따르기 때문에 HTTP 1.1에서 추가되었다. 303 응답은 모호하지 않도록 의도되었다. 303 응답의 경우에 대해서는 리다이렉트 된 GET과 POST 요청을 따르고 307 응답의 경우에는 GET 요청만 따른다. 몇 가지 이유로 HttpServletResponse에는 이 상태코드에 해당하는 상수가 없다.
400 Bad Request
요청에 문법적으로 잘못된 부분이 있음.
401 Bad Request
클라이언트가 올바른 허가를 받지 않고 허가가 필요한 페이지에 접근하려 함. 여기에 대한 응답으로 브라우저가 대화창을 열어 사용자 이름과 암호를 받아들이도록 하는 WWW-Authenticate 헤더를 포함해야 한다.
403 Forbidden
사용 권한에 관계없이 내용을 볼 수 없음. 종종 파일 이름이 잘못되었거나 서버의 디렉터리 퍼미션이 잘못 되었을 때 나온다.
404 Not Found
이 주소에서는 어떤 내용도 발견할 수 없음. 이것은 표준 ‘no such page'응답이다. 이 상태 코드는 아주 일반적인 응답이다. 그래서 이 상태코드를 위한 HttpServletResponse:sendError(message)라는 특별한 메소드가 있다. sendError는 serStatus에 비해 에러 메시지를 보여주는 에러 페이지를 자동적으로 만들어 준다는 장점이 있다.
405 Method Not Allowed
요청 메소드(GET, POST, HEAD, DELETE, PUT, TRACE 등) 를 특정 자원에 대해서는 쓸 수 없음.
406 Not Acceptable
지정된 자원이 클라이언트의 Accept 헤더에 명시된 것과 호환 되지 않는 MIME content-type을 생성함.
407 Proxy Authentication Required
401과 비슷하지만 서버가 Proxy-Authenticate 헤더를 반환해야 한다.
408 Request Timeout
클라이언트가 요청을 보내는 데 너무 오랜 시간이 걸림.
409 Conflict
보통 PUT 요청과 관계 있다. 보통 틀린 버전의 파일을 업로드할 경우 발생한다.
410 Gone
문서가 사라졌고 포워딩할 주소도 없음. 404와 다른 점은 이 경우 문서가 완전히 사라졌다는 것을 서버가 안다는 점이다. 404는 어떤 이유인지는 모르는데 단지 요청한 것을 사용할 수 없다는 것을 의미한다.
411 Length Required
클라이언트가 Content-Length를 보내지 않으면 서버가 처리할 수 없음.
412 Precondition Failed
요청 헤더에 설정되어 있는 어떤 조건이 맞지 않음.
413 Request Entity Too Large
요청된 문서가 현재 서버가 다룰 수 있는 크기보다 큼. 만약 서버에서 나중에 다룰 수 있다고 생각되면 Retry-After 헤더를 포함시켜야 한다. (HTTP 1.1에서 새로 등장)
414 Request URI Too Long
URI가 너무 길다.
415 Unsupported Media Type
요청이 알려지지 않은 형태임
416 Requested Range Not Satisfiable
클라이언트가 요청에 적당하지 않은 Range 헤더를 포함시켰음
417 Expectation Failed
Expect 요청 헤더의 값이 맞지 않음.
500 Internal Server Error
일반적인 ‘server is confused' 메시지. 종종 CGI 프로그램이나 서블릿의 결과가 잘못되거나 적절하지 않은 헤더를 만들었을 때 발생한다.
501 Not Implemented
요청한 것을 서버에서 지원하지 않음. 예를 들면 클라이언트가 서버에서 지원하지 않는 PUT과 같은 명령을 내렸을 때 발생한다.
502 Bad Gateway
프록시나 게이트웨이의 역할을 하는 서버에서 볼 수 있다. 초기 서버가 원격 서버로부터 부적절한 응답을 받았음을 나타낸다.
503 Service Unavailable
처리할 수 있는 한계를 벗어나 과도하게 요청이 들어와서 서버가 응답할 수 없음. 예를 들면 스레드나 데이터베이스 연결이 가득 차 있을 때 서블릿에서 이런 헤더를 반환한다. 서버는 Retry-After 헤더를 낼 수 있다.
504 Gateway Timeout
프록시나 게이트웨이의 역할을 하는 서버에서 볼 수 있다. 초기 서버가 원격 서버로부터 응답을 받을 수 없음을 나타낸다.
505 HTTP Version Not Supported
서버가 요청 라인에 지정된 HTTP 버전을 지원하지 않음.


Trackbacks 0 : Comments 0
위로
스팸메일에 대한 통계와 극복 방안
호스팅 상식 | 2008. 3. 11. 13:37


우리가 사용하는 이메일에서 정상적인 내용은 얼마나 될까. 한 기업에서 이러한 스팸메일에 대한 조사를 한 결과 정상메일은 전체 6.5%에 불과한 것으로 나타났다. 100통 당 6.5개인 셈이다. 나머지 93.5%는 스팸, 거부메일 등 쓰레기라는 의미다.

지난해 동안 이용자들이 받은 스팸메일은 대략 7억6000만 개로 전체 메일 중 약 92.7%를 차지했다. 더구나 이용자들은 상반기보다 하반기로 갈수록 더 많이 스팸 메일을 받아 연말로 갈수록 스팸 메일이 증가함을 보여줬다.

출처 : 보안뉴스
http://www.boannews.com/media/view.asp?page=1&idx=9010&search=&find=&kind=1

이는 스팸제공자의 99.04%가 단속에서 자유롭다라고 나와 있듯이 앞으로 단속에 의해 줄어들지는 않을 것이다.

구글메일의 경우 스팸차단 기능을 제공하니, 차라리 구글메일을 이용함으로써 사용자 자체로 스팸을 줄이는 것도 방법이 될것이다.


Trackbacks 0 : Comments 0
위로
서버호스팅에서 대역폭, 트래픽, 페이지뷰 환산 방식
호스팅 상식 | 2007. 5. 18. 19:57


서버호스팅과 코로케이션 서비스 이용 시 순간대역폭 과금방식으로 월 이용료를 내게 됩니다.
이때 순간대역폭이라는 과금방식이라는 용어가 이해가 안되는 경우가 있습니다.


순간대역폭이라 함은 초당 전송량이며 단위는 bps입니다. 이를 우리가 잘아는 메가(M), 기가(G)로 환산하면 이해하기가 쉽습니다. 대개 순간대역폭 5M를 기준으로 기본요금을 잡는데, 5M란 순간대역폭 5Mbps라는 이야기입니다.


[하루 트래픽 환산]

5Mbps * (24시간 * 60분 * 60초)
= 432,000Mbps (bit 기준)
= 432,000Mbps / 8 (1 byte는 8 bit)
= 54,000Mbyte
= 54Gbyte (일전송량)
= 1,620Gybte (월전송량)

즉, 순간대역폭 5M라함은 하루 트래픽 54Gbps라는 의미입니다.


[일간 페이지 뷰]

대략 웹페이지 1 Page당 용량을 100Kbyte로 잡는다면
순간대역폭 5Mbps에서는 540,000 페이지뷰 정도를 소화해 낼수 있습니다.


Trackbacks 0 : Comments 2
위로
From. 2011.03.22 11:40
PERMALINKDELETE/MODIFYREPLY
비밀댓글입니다
From. Favicon of https://www.allhost.co.kr BlogIcon 올호스트 URECA 2011.03.23 13:38 신고
PERMALINKDELETE/MODIFY
다시 계산을 해보니 맞네요^^ 지적 감사합니다.
이전 페이지
[1]
다음 페이지
보이기/숨기기 가능합니다^^
2016년 2016
손님 2014
최재복 2013
아 진짜 정말 너무 유용한 정보였습니다. 2013
스마일서브 2013
유료랍니다.소송도 진행되는,, 2013
illa 2013
오래쓴사람 2012
써봤더니... 2012
초보자 2012
김성민 2012
skup złota 2012
금융경제 인사이드 2011
올호스트 URECA 2011
올호스트 URECA 2011



  RSSFeed