웹 갤럭시에 대한 SysAdmin 가이드

게시 됨: 2021-07-19

웹에서 접할 수 있는 많은 기술 용어가 있으며 인터넷 사용자라면 대부분의 용어를 숙지하는 것이 중요합니다. 이 게시물은 많은 기본 용어에 대한 통찰력을 제공하고 웹 사이트에서 일반적인 오류 및 발생을 처리하는 방법에 대한 지침을 제공하며 인터넷을 더 이해하기 쉽게 만들 것입니다.

인터넷은 종종 위압적이고 낯설게 느껴질 수 있는 많은 정보와 용어가 있는 무서운 곳이 될 수 있습니다. 그러나 업무의 일부로 인터넷을 사용하는 사람이라면 누구나 편안해야 하는 몇 가지 사항이 있습니다. 아래에서 일반적인 용어와 개념의 전체 목록을 작성했습니다.

DNS란 무엇입니까?

DNS는 도메인 이름 시스템(Domain Name System)의 약자이며 간단히 말해서 브라우저에 원격 리소스를 찾을 위치를 알려주는 것입니다. 일반적으로 123-Reg, GoDaddy 등과 같은 도메인 이름 공급자 또는 CloudFlare, Sucuri 및 Office 365와 같은 타사 서비스를 통해 관리됩니다. DNS 레코드를 제어하는 사람을 이해하는 것이 중요합니다. www를 통해 웹사이트에 액세스하는 것을 허용하는 것부터 웹사이트의 측면 이메일 인증에.

DNS는 전 세계적으로 배포되기 때문에 DNS 변경 사항이 변경되는 데 일정 시간이 걸립니다. 이를 일반적으로 TTL(Time To Live)이라고 합니다. 대부분의 제공자는 4시간마다 기록을 업데이트합니다. 실질적으로 이것은 새로운 웹사이트로 이동할 때 인터넷의 모든 사람이 정상적으로 볼 수 있을 때까지 최대 48시간이 걸린다는 것을 의미합니다.

다음은 DNS 레코드에 대해 자세히 설명하는 기사입니다. DNS란.

캐싱이란 무엇입니까?

캐싱은 향후 사용을 위해 저장된 데이터를 참조하는 컴퓨팅 개념입니다. 이것은 주로 속도와 자원 절약의 두 가지 이유로 수행됩니다. 예를 들어 캐싱이 없으면 브라우저를 새로 고칠 때마다 서버에서 이 페이지의 새 버전을 만들어야 합니다. 게시된 후에는 실시간 업데이트가 없기 때문에 리소스를 크게 낭비하는 것입니다. 또한 페이지 자체를 생성하기 전에 서버에서 많은 작업을 처리해야 하므로 상대적으로 느립니다. 캐싱이 활성화된 상태에서 누군가 이 블로그 게시물에 처음 액세스하면 서버에서 이를 생성하고 저장하므로 이후의 모든 방문자에게 해당 버전이 제공됩니다.

정보를 캐싱하는 것은 서버만이 아닙니다. 대부분의 브라우저도 정보를 캐싱합니다. 페이지에 한 번 액세스하면 서버는 페이지의 일부 정보를 저장하고 기억하므로 동일한 웹 페이지를 다시 방문할 때 캐시가 무효화되지 않는 한 브라우저는 네트워크에 의존. 일반적으로 무언가가 즉시 업데이트되지 않는 경우 일부 캐싱 메커니즘 때문입니다.

일련의 슬라이드로 캐싱 설명: Caching Explained.
캐시를 지우는 방법: 웹 브라우저의 캐시를 지우십시오.

SSL이란 무엇입니까/내 사이트는 안전합니까?

SSL 인증서는 웹 사이트의 ID를 확인하고 서버와 클라이언트 간의 통신을 암호화하는 파일입니다. 특히 과거에는 모든 웹사이트에 SSL 인증서가 필요한 것은 아닙니다. 그러나 최근 변경 사항과 보안 문제가 증가함에 따라 하나를 보유하는 것이 좋습니다. Google 크롬은 SSL 인증서를 사용하지 않는 웹사이트를 안전하지 않은 것으로 이미 표시하기 시작했습니다.

진실은 댓글이 없고 전화번호와 주소가 없는 블로그나 뉴스피드가 있는 대부분 정적 웹사이트가 있다면 실제로 필요하지 않다는 것입니다. 클라이언트는 웹사이트에 데이터를 제공하지 않으므로 아무 것도 암호화할 필요가 없습니다. 그러나 웹 사이트에 SSL 인증서가 없을 이유가 없습니다. Let's Encrypt와 같은 무료 SSL 인증서를 제공하는 조직이 있습니다. 그러나 암호화 표준이 다르기 때문에 모든 SSL 인증서가 동일한 목적에 적합한 것은 아닙니다. 따라서 전자 상점과 같은 응용 프로그램의 경우 더 강력한 암호화가 포함된 SSL 인증서를 사용해야 합니다.

SSL에 대한 자세한 설명: SSL 인증서란 무엇입니까?

HTTP 상태 코드

다른 많은 프로토콜과 마찬가지로 HTTP에는 다양한 상태를 보고하기 위해 포함된 상태 코드 세트가 있습니다. 실제로 http(s)를 통해 리소스에 액세스할 때마다 코드 200이 반환됩니다. 일상적인 브라우징 중에 경험할 수 있는 많은 코드가 있으므로 실제로 의미하는 바를 이해하는 것이 유용합니다.

404 리소스를 찾을 수 없습니다. 존재하지 않는 리소스를 요청할 때
403 금지. 해당 특정 리소스에 액세스하도록 인증되지 않았습니다.
502 잘못된 게이트웨이. 서버가 잘못된 응답을 받았습니다.
503 사용할 수 없습니다. 일반적으로 서버 유지 관리 또는 다운타임 중에 반환됩니다.
500 내부 서버 오류입니다. 서버 구성에 문제가 있습니다.
301/302 영구/임시 이전

HTTP 상태 코드에 대한 자세한 내용은 Wikipedia HTTP 상태 코드에서 확인할 수 있습니다.

.htaccess 파일이란 무엇입니까?

일반적으로 들어본 파일 이름은 htaccess입니다. 이것은 Apache 서버를 구성할 수 있는 파일이며 웹 사이트를 실행하는 데 필요한 리디렉션을 포함하는 가장 일반적인 위치입니다. htaccess 파일과 마찬가지로 Windows 및 Nginx 서버용 web.config 및 nginx.config도 있습니다. 일부 CMS 시스템은 기본적으로 또는 플러그인을 통해 이러한 파일을 노출하지만 제대로 처리되지 않으면 서버가 오프라인 상태가 될 수 있으므로 변경할 때 주의하는 것이 매우 중요합니다.

.htaccess는 무엇입니까: www.htaccess-guide.com.
Nginx 구성 이해: DigitalOcean
Web.config 파일을 만드는 방법: MSDN.

웹 서버 란 무엇입니까?

"웹 서버"라는 용어는 하드웨어 및 소프트웨어 구성 요소를 모두 포함하는 광범위한 구성 요소를 나타낼 수 있습니다. 하드웨어 수준에서 웹 서버는 소프트웨어, 웹 응용 프로그램의 파일 및 설정을 저장하는 기계이므로 리소스를 배포할 목적으로 외부 연결을 허용합니다. 특수 서버 머신일 수도 있고 단순한 랩탑일 수도 있습니다. 웹 서버를 구동하는데 사용할 수 있는 소프트웨어는 용도에 따라 다르지만, 웹 서버의 가장 일반적인 유형 중 하나는 Apache입니다.

그러나 모든 웹 서버가 모든 유형의 웹사이트를 실행할 수 있는 것은 아닙니다. 예를 들어 ASP.net으로 구축된 DNN에서 실행되는 웹 사이트가 있는 경우 Apache 서버에서 실행되지 않습니다.

웹 서버란 무엇입니까? developer.mozilla.org.

웹사이트에서 오류 발생

웹사이트나 웹 애플리케이션은 본질적으로 살아 있는 제품이기 때문에 평생 동안 끊임없이 변화하므로 결국 몇 가지 오류가 발생합니다. 가장 중요한 것은 당황하지 말고 오류를 인식하고 시도하는 것입니다. 이에 대한 규정이 있으므로 시스템 관리자와 개발자는 사용자의 여정을 전체적으로 추적할 수 없습니다. 오류를 인식하고 분류를 시도하고 유익한 오류 보고서를 작성하면 개발자가 도움을 줄 수 있습니다.

경우에 따라 발생한 오류는 시스템에 따라 다르며 다른 시스템에 복제할 수 없습니다. 그러나 웹에서 접할 수 있는 일반적인 오류가 많이 있습니다. 다음은 가능한 원인 및 해결 방법과 함께 간단한 오류 목록입니다.

변경 사항이 표시되지 않음: 예를 들어 웹 사이트에 새 블로그 게시물을 추가했지만 홈페이지의 뉴스 피드에 표시되지 않거나 페이지에 콘텐츠를 추가하는 등 즉시 반영되지 않는 변경 사항이 표시될 것으로 예상되는 경우 그러나 미리 보기에 표시되지 않는 경우 일부 캐싱 메커니즘으로 인한 것일 수 있습니다. 웹사이트에서 사용하는 캐싱 시스템에 따라 서버 또는 브라우저 수준에서 캐시를 수동으로 지워야 할 가능성이 있습니다.
깨진 페이지 스타일: 페이지를 방문할 때 일부 스타일이 깨진 경우, 예를 들어 모든 것이 왼쪽 정렬로 표시되고 글꼴이 로드되지 않는 경우 이러한 일이 발생할 수 있는 몇 가지 이유가 있습니다. 이는 특히 웹사이트의 코드가 최근에 업데이트된 경우 캐싱으로 인해 발생할 수 있습니다. 다른 일반적인 원인 중 일부는 서버에서 리소스를 찾을 수 없거나(이전에 언급한 404 상태 코드) 리소스를 로드하는 동안 네트워크 또는 브라우저에 오류가 발생하여 전송이 취소되었을 수 있습니다. 후자는 약한 네트워크 상태로 인해 발생할 수 있습니다. 예를 들어 신호가 약한 모바일 장치에서 웹사이트에 액세스합니다. 이런 종류의 문제가 발생할 때마다 다른 브라우저에서 웹사이트에 액세스해 보십시오.
예상과 다른 페이지 방문: 이 경우 특정 웹 페이지에 대한 모든 요청을 강제로 다른 페이지 로 리디렉션하는 리디렉션이 있을 수 있습니다. 이는 사이트별 구성, 의도적인 리디렉션 또는 악성 코드로 인해 발생할 수 있습니다. 예를 들어 WordPress는 리디렉션을 사용하여 사용자가 기본 URL에 대해 다른 URL을 사용할 수 있도록 합니다. 기본적으로 모든 WordPress 게시물 및 페이지는 www.example.com/?p=123을 통해 액세스됩니다. 그러나 이것은 변경될 수 있으므로 p=123 대신 실제 게시물 이름을 사용합니다. 이것은 부분적으로 리디렉션 때문입니다. 악의적인 리디렉션은 해킹된 사이트에 있으며 그 전체 목적은 모든 트래픽을 해커의 웹사이트로 리디렉션하는 것이며 일반적으로 서버 구성이 아닌 페이지 내 스크립팅을 통해 수행됩니다. 참고로 이는 브라우저가 리디렉션을 캐시하는 경향이 있기 때문에 캐싱으로 인해 발생할 수도 있습니다. 브라우저가 이전 버전으로 리디렉션하려고 시도하는 경우가 많기 때문에 기존 웹 사이트를 처음 교체할 때 이는 정말 분명합니다.
너무 많은 리디렉션: 캐싱 때문일 수도 있습니다. 그러나 대부분의 경우 끝없는 리디렉션 루프로 인해 발생합니다. 예를 들어 웹 사이트의 홈페이지를 자체적으로 리디렉션하려고 합니다.
연결이 안전하지 않음/비공개: https://를 통해 웹사이트에 액세스하려고 할 때 SSL 인증서가 없거나 잘못된 SSL 인증서가 설치된 경우 나타납니다. 오래된 브라우저를 사용하여 보안 웹사이트에 액세스하는 보다 드문 원인도 있습니다. 그러나 이 경우 Internet Explorer 8 또는 2000년대 중반의 다른 브라우저를 사용해야 합니다.
빈 흰색 페이지: 이것은 최악의 유형의 오류이며 대부분의 웹 개발자가 개발 중에 정기적으로 경험하는 것입니다. 이 경우 서버에 문제가 발생하여 어떤 식으로든 연결이 종료된 것입니다. 이는 잘못된 응용 프로그램 코드 또는 htaccess 파일의 잘못된 구성으로 인해 발생할 수 있습니다. 이것은 라이브 웹사이트에서 일반적으로 볼 수 있는 것이 아니며 개발자가 일반적으로 해결해야 하는 것입니다.

위에서 언급했듯이 오류를 IT 회사에 알리는 것은 오류를 해결하는 데 가장 중요한 부분 중 하나입니다. 문제를 보고할 때 포함할 수 있는 정보가 많을수록 일반적으로 개발자가 문제를 시도하고 복제하는 데 소비해야 하는 시간이 줄어들기 때문에 해결 속도가 빨라집니다. 또는 문제가 발생한 시간에 대한 서버 로그를 참조하십시오.

황금률은 없지만 버그 보고서에 제공해야 하는 항목의 예는 다음과 같습니다.

이 문제를 처음 경험한 때는 언제입니까?
문제의 스크린샷
문제의 페이지 URL
브라우저 버전
운영 체제
네트워크 유형(WiFi / 4G)
귀하의 IP 주소

이 웹사이트(https://www.whatsmybrowser.org/)와 같이 이 모든 정보를 제공하는 데 도움이 되는 도구도 있습니다. 이 웹사이트에서는 브라우저 정보의 공유 가능한 URL도 제공합니다.

이미지가 중요한 이유

대부분의 사람들은 웹사이트의 멋진 이미지를 높이 평가하며 최고 품질의 4k 이미지를 보고 싶어합니다. 그러나 이것은 많은 문제를 일으키기 때문에 적어도 비 갤러리 페이지에서 웹 사이트와 관련하여 매우 나쁜 생각입니다. 가장 중요한 것은 페이지에 하나의 큰 이미지를 포함하더라도 웹사이트의 로드 속도를 크게 줄일 수 있다는 것입니다. 예를 들어 페이지에 2MB의 이미지를 추가하면 이미지가 로드될 때까지 2초의 지연을 기대할 수 있습니다.

또한 웹 사이트 레이아웃은 대부분 특정 이미지 종횡비로 구축됩니다. 따라서 정사각형이 예상되는 영역에서 가로 이미지를 사용하려고 하면 잘립니다. 적합하지 않은 이미지를 사용하는 경우 일부 레이아웃에 영향을 줄 수 있으므로 최소 및 최대 치수도 고려해야 합니다.

문의 양식 이메일이 스팸 폴더로 이동하는 이유

웹사이트의 이메일이 스팸 폴더에 도달하거나 받은 편지함에 전혀 들어가지 않는 데에는 여러 가지 이유가 있습니다. 이러한 경우의 대부분은 스팸 필터에 의해 이메일이 걸려서 발생합니다. 대부분의 경우 이메일 발신자는 이메일 클라이언트 또는 이메일 제공업체의 화이트리스트에 있어야 합니다. 또 다른 일반적인 오류는 다른 이메일 주소를 사용하여 도메인에 있는 이메일 주소로 이메일을 보내는 것입니다. 예를 들어, Gmail 주소를 통해 hallam.co.uk 문의 양식에서 이메일을 보내려고 시도했다면 성공적으로 전달되지 않을 가능성이 높습니다.

이 문제를 해결하려면 일반적으로 아래 단계 중 하나를 수행해야 합니다.

도메인과 일치하는 주소에서 이메일을 보내도록 연락처 양식을 수정합니다. 이것은 "실제" 주소일 필요는 없으며 일반적으로 [email protected]이 사용됩니다.
도메인에 SPF 레코드를 추가하여 전송된 이메일 확인
이메일 주소를 사용하고 이메일을 보내기 전에 인증하십시오.
MailGun과 같은 외부 메일 배달 서비스 사용

문의 양식이 스팸 제출을 많이 받는 이유

스팸은 자동 또는 수동으로 생성될 수 있으며 항상 웹사이트가 손상되었다는 신호는 아닙니다. 많은 경우 봇이 연락처 양식을 검색한 다음 메시지를 공통 필드에 매핑하여 광고를 제출합니다. 이것은 채워진 경우 연락처 양식을 제출하지 않는 허니팟 필드를 도입하여 쉽게 중지할 수 있습니다.

이것이 수동 스팸이나 고급 봇을 차단하는 것이 아니므로 대안은 봇이 완료할 수 없는 "인간" 테스트입니다. 현재 표준은 reCAPTCHA를 구현하고 있습니다. 그러나 간단한 수학 퀴즈와 같은 다양한 방법이 사용되었습니다.

갑자기 인터넷이 더 이상 무섭게 느껴지지 않죠? 웹 디자인 및 개발에 대한 도움이 필요하면 지금 당사 전문가에게 문의하십시오.